From nobody Mon Jul 5 13:15:10 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 94C898D3348 for ; Mon, 5 Jul 2021 13:15:18 +0000 (UTC) (envelope-from petefrench@ingresso.co.uk) Received: from constantine.ingresso.co.uk (constantine.ingresso.co.uk [IPv6:2001:470:6a18:411::3]) (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 4GJR4j36Lxz3MZw for ; Mon, 5 Jul 2021 13:15:17 +0000 (UTC) (envelope-from petefrench@ingresso.co.uk) Received: from [2001:470:6cc4:1:cd6:5836:ddba:7b54] (helo=balta.drayhouse.twisted.org.uk) by constantine.ingresso.co.uk with esmtpsa (TLS1.3) tls TLS_AES_128_GCM_SHA256 (Exim 4.94.2 (FreeBSD)) (envelope-from ) id 1m0ORK-000Ngk-J8 for freebsd-stable@freebsd.org; Mon, 05 Jul 2021 13:15:10 +0000 To: FreeBSD Stable Mailing List From: Pete French Subject: ZFS + mysql appears to be killing my SSD's Message-ID: <89c37c3e-22e8-006e-5826-33bd7db7739e@ingresso.co.uk> Date: Mon, 5 Jul 2021 14:15:10 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 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=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4GJR4j36Lxz3MZw X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=ingresso.co.uk; spf=pass (mx1.freebsd.org: domain of petefrench@ingresso.co.uk designates 2001:470:6a18:411::3 as permitted sender) smtp.mailfrom=petefrench@ingresso.co.uk X-Spamd-Result: default: False [0.67 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[2001:470:6a18:411::3:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2001:470:6a18:411::3]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_MEDIUM(1.00)[0.999]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[2001:470:6a18:411::3:from:127.0.2.255]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.36)[-0.364]; DMARC_POLICY_ALLOW(-0.50)[ingresso.co.uk,none]; NEURAL_SPAM_LONG(0.84)[0.836]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-stable]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N I hve a netwkr of FreeBSD machines which are running mysql on top of zfs. I have been doing this for a while, but a couple of years ago we switched to using SSD. After less than a year (I dont remember the exact timings), they all strated to fail. We assumed a bad batch, and had them replaced, and didnt think anything more of it. A week or so, all the replacements started to fail. This was shortly after I upgraded to FreeBSD 13 and OpenZFS, but I think this is unrelated, however its one major chnage which happened before the most recent round of failures. The thing is though, that I am not seieng any heavy activity on the drives. The load is sustained, but well below the lifetime write thresh-hold for the drive. I also do not see the drives a being heavily in use when I run gstat. So its perplexing. I am assuming its related to the mysql load, as this is identical across all machines, and they are all dying within a few days of each other. Any insights would be appreciated... :-) -pete. From nobody Mon Jul 5 13:37: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 928F48D62F2 for ; Mon, 5 Jul 2021 13:37:13 +0000 (UTC) (envelope-from se@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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 (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GJRZ13fqBz3QSJ; Mon, 5 Jul 2021 13:37:13 +0000 (UTC) (envelope-from se@freebsd.org) Received: from Stefans-MBP-449.fritz.box (p200300cd5f18b2006c175e4403fd7f12.dip0.t-ipconnect.de [IPv6:2003:cd:5f18:b200:6c17:5e44:3fd:7f12]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: se/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id F18A72BFA4; Mon, 5 Jul 2021 13:37:12 +0000 (UTC) (envelope-from se@freebsd.org) To: Pete French References: <89c37c3e-22e8-006e-5826-33bd7db7739e@ingresso.co.uk> From: Stefan Esser Cc: FreeBSD Stable Mailing List Subject: Re: ZFS + mysql appears to be killing my SSD's Message-ID: <2fd9b7e4-dc75-fedc-28d7-b98191167e6b@freebsd.org> Date: Mon, 5 Jul 2021 15:37:09 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 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 In-Reply-To: <89c37c3e-22e8-006e-5826-33bd7db7739e@ingresso.co.uk> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="lVKaSy8oz6R3Z7xTaC4N8EB1I8WYkYlV5" X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --lVKaSy8oz6R3Z7xTaC4N8EB1I8WYkYlV5 Content-Type: multipart/mixed; boundary="EA0fJvzZWDXOGTOUZNr1x5kbXiRTj9EJC"; protected-headers="v1" From: Stefan Esser To: Pete French Cc: FreeBSD Stable Mailing List Message-ID: <2fd9b7e4-dc75-fedc-28d7-b98191167e6b@freebsd.org> Subject: Re: ZFS + mysql appears to be killing my SSD's References: <89c37c3e-22e8-006e-5826-33bd7db7739e@ingresso.co.uk> In-Reply-To: <89c37c3e-22e8-006e-5826-33bd7db7739e@ingresso.co.uk> --EA0fJvzZWDXOGTOUZNr1x5kbXiRTj9EJC Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Am 05.07.21 um 15:15 schrieb Pete French: > I hve a netwkr of FreeBSD machines which are running mysql on top of zf= s. I > have been doing this for a while, but a couple of years ago we switched= to > using SSD. After less than a year (I dont remember the exact timings), = they all > strated to fail. We assumed a bad batch, and had them replaced, and did= nt think > anything more of it. >=20 > A week or so, all the replacements started to fail. This was shortly af= ter I > upgraded to FreeBSD 13 and OpenZFS, but I think this is unrelated, howe= ver its > one major chnage which happened before the most recent round of failure= s. >=20 > The thing is though, that I am not seieng any heavy activity on the dri= ves. The > load is sustained, but well below the lifetime write thresh-hold for th= e drive. > I also do not see the drives a being heavily in use when I run gstat. S= o its > perplexing. I am assuming its related to the mysql load, as this is ide= ntical > across all machines, and they are all dying within a few days of each o= ther. >=20 > Any insights would be appreciated... :-) Hi Pete, have you checked the drive state and statistics with smartctl? This is the output that I get from my SSD after use as a L2ARC for 1 year= : $ smartctl -d nvme /dev/nvme0 -a =2E.. =3D=3D=3D START OF SMART DATA SECTION =3D=3D=3D SMART overall-health self-assessment test result: PASSED SMART/Health Information (NVMe Log 0x02) Critical Warning: 0x00 Temperature: 27 Celsius Available Spare: 100% Available Spare Threshold: 5% Percentage Used: 1% Data Units Read: 11,745,658 [6.01 TB] Data Units Written: 14,767,823 [7.56 TB] Host Read Commands: 522,309,835 Host Write Commands: 69,368,834 Controller Busy Time: 1,198 Power Cycles: 40 Power On Hours: 8,514 Unsafe Shutdowns: 28 Media and Data Integrity Errors: 0 Error Information Log Entries: 120 Warning Comp. Temperature Time: 0 Critical Comp. Temperature Time: 0 Error Information (NVMe Log 0x01, 16 of 63 entries) No Errors Logged That drive has a spec of 600 TB TBW and I seem to have used 1% of that wi= thin that year of use. Regards, STefan --EA0fJvzZWDXOGTOUZNr1x5kbXiRTj9EJC-- --lVKaSy8oz6R3Z7xTaC4N8EB1I8WYkYlV5 Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEo3HqZZwL7MgrcVMTR+u171r99UQFAmDjCwUFAwAAAAAACgkQR+u171r99UQ3 kwf/QsSKxLxPo0A4yX6NzXft8K8uMfFE3vofIv3mBJz9v7SHAoDsdHuIpRzlzQf47cLSWLdlSm5S nbXYoyCxuFWJWik1gAbimWGFK5ei9/z/QurYYuHIxN11KH168ZFf+Lp+D8XjXVrFVU5I87n2ljQe f2Mifd+/BCuq3MLVVt7F/iuImZHrl3ap9pZ7dVFqLb+/wEA0GwKv2ai8yYjTEMDUsPoMYwJRkGt1 K08DvqdqeolBwc+SR1DI56YHadZkHoCjEmifOM4Uwcd4sScu183EHgG914VcPku3OfSNpeMEN4YB wT0GVqzhGZGI99JCoDnsgNKoKZj833ffjSGFP8txVw== =vUnr -----END PGP SIGNATURE----- --lVKaSy8oz6R3Z7xTaC4N8EB1I8WYkYlV5-- From nobody Mon Jul 5 14:30:43 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 72D8C11D059D for ; Mon, 5 Jul 2021 14:30:48 +0000 (UTC) (envelope-from petefrench@ingresso.co.uk) Received: from constantine.ingresso.co.uk (constantine.ingresso.co.uk [IPv6:2001:470:6a18:411::3]) (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 4GJSlr2xHXz3qQK; Mon, 5 Jul 2021 14:30:48 +0000 (UTC) (envelope-from petefrench@ingresso.co.uk) Received: from [2001:470:6cc4:1:cd6:5836:ddba:7b54] (helo=balta.drayhouse.twisted.org.uk) by constantine.ingresso.co.uk with esmtpsa (TLS1.3) tls TLS_AES_128_GCM_SHA256 (Exim 4.94.2 (FreeBSD)) (envelope-from ) id 1m0PcU-000Nm1-2P; Mon, 05 Jul 2021 14:30:46 +0000 Subject: Re: ZFS + mysql appears to be killing my SSD's To: Stefan Esser Cc: FreeBSD Stable Mailing List References: <89c37c3e-22e8-006e-5826-33bd7db7739e@ingresso.co.uk> <2fd9b7e4-dc75-fedc-28d7-b98191167e6b@freebsd.org> From: Pete French Message-ID: <9c71d627-55b8-2464-6cc9-489e4ce98049@ingresso.co.uk> Date: Mon, 5 Jul 2021 15:30:43 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 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 In-Reply-To: <2fd9b7e4-dc75-fedc-28d7-b98191167e6b@freebsd.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4GJSlr2xHXz3qQK X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: N On 05/07/2021 14:37, Stefan Esser wrote: > Hi Pete, > > have you checked the drive state and statistics with smartctl? Hi, thanks for the reply - yes, I did check the statistics, and they dont make a lot of sense. I was just looking at them again in fact. So, one of the machines that we chnaged a drive on when this first started, which was 4 weeks ago. root@telehouse04:/home/webadmin # smartctl -a /dev/ada0 | grep Perc 169 Remaining_Lifetime_Perc 0x0000 082 082 000 Old_age Offline - 82 root@telehouse04:/home/webadmin # smartctl -a /dev/ada1 | grep Perc 202 Percent_Lifetime_Remain 0x0030 100 100 001 Old_age Offline - 0 Now, from that you might think the 2nd drive was the one changes, but no. Its the first one, which is now at 82% lifetime remaining! The other druve, still at 100%, has been in there a year. The drives are different manufacturers, which makes comparing most of the numbers tricky unfortunately. Am now even more worried than when I sent the first email - if that 18% is accurate then I am going to be doing this again in another 4 months, and thats not sustainable. It also looks as if this problem has got a lot worse recently. Though I wasnt looking at the numbers before, only noticing tyhe failurses. If I look at 'Percentage Used Endurance Indicator' isntead of the 'Percent_Lifetime_Remain' value then I see some of those well over 200%. That value is, on the newer drives, 100 minus the 'Percent_Lifetime_Remain' value, so I guess they ahve the same underlying metric. I didnt mention in my original email, but I am encrypting these with geli. Does geli do any write amplification at all ? That might explain the high write volumes... -pete. From nobody Mon Jul 5 14:51:14 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 C596A11D4637 for ; Mon, 5 Jul 2021 14:51:26 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-oi1-f170.google.com (mail-oi1-f170.google.com [209.85.167.170]) (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 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GJTCf54Svz3vN5; Mon, 5 Jul 2021 14:51:26 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-oi1-f170.google.com with SMTP id s24so5941851oiw.2; Mon, 05 Jul 2021 07:51:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BSAzkRd4GVbQURAXfzf+DvLDUD9dTpRUkR6i2VAG6f0=; b=DLIpc0f8zNw1qB6qbMtPnsMpGH+s7Yd/j0hx8iS5jfXkgeGtNRE7Kq4T8Aif4wvQlN ne4/b+Y3Fp9ZSGRziUW2Q7FDQ9mMTwQJw8D4Mz2l2Wle6irRl2lD27o6bCN1W+fKy4pU wkieAk1quHTSfI6evBm/WV9K22br9twIUb+P1VZtkHVpNRsG0stqMd+SmcP1Fnv5gHnH Xg/ELhLyqongFWNCPiTFxu2EmEMeJxC34IuaDYFOmrIDTbojhNWtGqTVJmEx3dbEtVuZ lOKmi3v1ULMvFsTfffv4YoJQB2hSWXdpimLfifMk4SVDqihpmk/mbr6j9JrdxIk8IXw/ /GuA== X-Gm-Message-State: AOAM5338LmPJffI0/9fK0L8FitwB/my3taOYuUCl3M4HkF4+nLBRdIbW Q+4PAQXUVOJDMu/BVkdqoTwvPcu2KY0ov0lFB2l7wqi/Ul0= X-Google-Smtp-Source: ABdhPJzeX8U0aZz5f2NkEwtncTrfvR2PdXPTs5IFPAjWuHnHtQOEd5NB9V5bgC8MNAFGVKRGkL2r2A8INKXGdAW0eSs= X-Received: by 2002:a05:6808:bc1:: with SMTP id o1mr10880362oik.55.1625496685629; Mon, 05 Jul 2021 07:51:25 -0700 (PDT) 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 References: <89c37c3e-22e8-006e-5826-33bd7db7739e@ingresso.co.uk> <2fd9b7e4-dc75-fedc-28d7-b98191167e6b@freebsd.org> <9c71d627-55b8-2464-6cc9-489e4ce98049@ingresso.co.uk> In-Reply-To: <9c71d627-55b8-2464-6cc9-489e4ce98049@ingresso.co.uk> From: Alan Somers Date: Mon, 5 Jul 2021 08:51:14 -0600 Message-ID: Subject: Re: ZFS + mysql appears to be killing my SSD's To: Pete French Cc: Stefan Esser , FreeBSD Stable Mailing List Content-Type: multipart/alternative; boundary="00000000000087d45205c661707a" X-Rspamd-Queue-Id: 4GJTCf54Svz3vN5 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y --00000000000087d45205c661707a Content-Type: text/plain; charset="UTF-8" On Mon, Jul 5, 2021 at 8:31 AM Pete French wrote: > > > On 05/07/2021 14:37, Stefan Esser wrote: > > Hi Pete, > > > > have you checked the drive state and statistics with smartctl? > > Hi, thanks for the reply - yes, I did check the statistics, and they > dont make a lot of sense. I was just looking at them again in fact. > > So, one of the machines that we chnaged a drive on when this first > started, which was 4 weeks ago. > > root@telehouse04:/home/webadmin # smartctl -a /dev/ada0 | grep Perc > 169 Remaining_Lifetime_Perc 0x0000 082 082 000 Old_age > Offline - 82 > root@telehouse04:/home/webadmin # smartctl -a /dev/ada1 | grep Perc > 202 Percent_Lifetime_Remain 0x0030 100 100 001 Old_age > Offline - 0 > > Now, from that you might think the 2nd drive was the one changes, but > no. Its the first one, which is now at 82% lifetime remaining! The other > druve, still at 100%, has been in there a year. The drives are different > manufacturers, which makes comparing most of the numbers tricky > unfortunately. > > > Am now even more worried than when I sent the first email - if that 18% > is accurate then I am going to be doing this again in another 4 months, > and thats not sustainable. It also looks as if this problem has got a > lot worse recently. Though I wasnt looking at the numbers before, only > noticing tyhe failurses. If I look at 'Percentage Used Endurance > Indicator' isntead of the 'Percent_Lifetime_Remain' value then I see > some of those well over 200%. That value is, on the newer drives, 100 > minus the 'Percent_Lifetime_Remain' value, so I guess they ahve the same > underlying metric. > > I didnt mention in my original email, but I am encrypting these with > geli. Does geli do any write amplification at all ? That might explain > the high write volumes... > > -pete. > If you're using 4K sectors anyway, then GELI does not create any extra write amplification. But if you're extra paranoid and you use the "-T" option to "geli attach", then GELI will block TRIM commands. That could hurt SSD lifetime. But I don't think "-T" is the default. You are using 4K sectors, right? ZFS's ashift is set to 12? -Alan --00000000000087d45205c661707a-- From nobody Mon Jul 5 15:09:37 2021 X-Original-To: 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 7F92811D7F3A for ; Mon, 5 Jul 2021 15:09:47 +0000 (UTC) (envelope-from karl@denninger.net) Received: from colo1.denninger.net (colo1.denninger.net [104.236.120.189]) (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 4GJTcp3clRz4S6P for ; Mon, 5 Jul 2021 15:09:46 +0000 (UTC) (envelope-from karl@denninger.net) Received: from denninger.net (096-033-205-208.res.spectrum.com [96.33.205.208]) by colo1.denninger.net (Postfix) with ESMTP id 543F82110CC for ; Mon, 5 Jul 2021 11:09:39 -0400 (EDT) Received: from [192.168.10.25] (D15.Denninger.Net [192.168.10.25]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by denninger.net (Postfix) with ESMTPSA id 5552D2F13B5 for ; Mon, 5 Jul 2021 11:09:39 -0400 (EDT) Subject: Re: ZFS + mysql appears to be killing my SSD's To: stable@freebsd.org References: <89c37c3e-22e8-006e-5826-33bd7db7739e@ingresso.co.uk> <2fd9b7e4-dc75-fedc-28d7-b98191167e6b@freebsd.org> <9c71d627-55b8-2464-6cc9-489e4ce98049@ingresso.co.uk> From: Karl Denninger Message-ID: Date: Mon, 5 Jul 2021 11:09:37 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 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 In-Reply-To: <9c71d627-55b8-2464-6cc9-489e4ce98049@ingresso.co.uk> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms030403050202080209050209" X-Rspamd-Queue-Id: 4GJTcp3clRz4S6P X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=denninger.net; spf=pass (mx1.freebsd.org: domain of karl@denninger.net designates 104.236.120.189 as permitted sender) smtp.mailfrom=karl@denninger.net X-Spamd-Result: default: False [-5.80 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; HAS_ATTACHMENT(0.00)[]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MIME_BASE64_TEXT(0.10)[]; DMARC_POLICY_ALLOW(-0.50)[denninger.net,none]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[104.236.120.189:from]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:14061, ipnet:104.236.64.0/18, country:US]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEFALL_USER(0.00)[karl]; FROM_HAS_DN(0.00)[]; SIGNED_SMIME(-2.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,multipart/alternative,text/plain]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:~]; PREVIOUSLY_DELIVERED(0.00)[stable@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[104.236.120.189:from:127.0.2.255]; MAILMAN_DEST(0.00)[stable] X-ThisMailContainsUnwantedMimeParts: Y This is a cryptographically signed message in MIME format. --------------ms030403050202080209050209 Content-Type: multipart/alternative; boundary="------------51B6809D4511225383F7526E" Content-Language: en-US This is a multi-part message in MIME format. --------------51B6809D4511225383F7526E Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: base64 T24gNy81LzIwMjEgMTA6MzAsIFBldGUgRnJlbmNoIHdyb3RlOg0KPg0KPg0KPiBPbiAwNS8w Ny8yMDIxIDE0OjM3LCBTdGVmYW4gRXNzZXIgd3JvdGU6DQo+PiBIaSBQZXRlLA0KPj4NCj4+ IGhhdmUgeW91IGNoZWNrZWQgdGhlIGRyaXZlIHN0YXRlIGFuZCBzdGF0aXN0aWNzIHdpdGgg c21hcnRjdGw/DQo+DQo+IEhpLCB0aGFua3MgZm9yIHRoZSByZXBseSAtIHllcywgSSBkaWQg Y2hlY2sgdGhlIHN0YXRpc3RpY3MsIGFuZCB0aGV5IA0KPiBkb250IG1ha2UgYSBsb3Qgb2Yg c2Vuc2UuIEkgd2FzIGp1c3QgbG9va2luZyBhdCB0aGVtIGFnYWluIGluIGZhY3QuDQo+DQo+ IFNvLCBvbmUgb2YgdGhlIG1hY2hpbmVzIHRoYXQgd2UgY2huYWdlZCBhIGRyaXZlIG9uIHdo ZW4gdGhpcyBmaXJzdCANCj4gc3RhcnRlZCwgd2hpY2ggd2FzIDQgd2Vla3MgYWdvLg0KPg0K PiByb290QHRlbGVob3VzZTA0Oi9ob21lL3dlYmFkbWluICMgc21hcnRjdGwgLWEgL2Rldi9h ZGEwIHwgZ3JlcCBQZXJjDQo+IDE2OSBSZW1haW5pbmdfTGlmZXRpbWVfUGVyYyAweDAwMDDC oMKgIDA4MsKgwqAgMDgywqDCoCAwMDDCoMKgwqAgT2xkX2FnZSANCj4gT2ZmbGluZcKgwqDC oMKgwqAgLcKgwqDCoMKgwqDCoCA4Mg0KPiByb290QHRlbGVob3VzZTA0Oi9ob21lL3dlYmFk bWluICMgc21hcnRjdGwgLWEgL2Rldi9hZGExIHwgZ3JlcCBQZXJjDQo+IDIwMiBQZXJjZW50 X0xpZmV0aW1lX1JlbWFpbiAweDAwMzDCoMKgIDEwMMKgwqAgMTAwwqDCoCAwMDHCoMKgwqAg T2xkX2FnZSANCj4gT2ZmbGluZcKgwqDCoMKgwqAgLcKgwqDCoMKgwqDCoCAwDQo+DQo+IE5v dywgZnJvbSB0aGF0IHlvdSBtaWdodCB0aGluayB0aGUgMm5kIGRyaXZlIHdhcyB0aGUgb25l IGNoYW5nZXMsIGJ1dCANCj4gbm8uIEl0cyB0aGUgZmlyc3Qgb25lLCB3aGljaCBpcyBub3cg YXQgODIlIGxpZmV0aW1lIHJlbWFpbmluZyEgVGhlIA0KPiBvdGhlciBkcnV2ZSwgc3RpbGwg YXQgMTAwJSwgaGFzIGJlZW4gaW4gdGhlcmUgYSB5ZWFyLiBUaGUgZHJpdmVzIGFyZSANCj4g ZGlmZmVyZW50IG1hbnVmYWN0dXJlcnMsIHdoaWNoIG1ha2VzIGNvbXBhcmluZyBtb3N0IG9m IHRoZSBudW1iZXJzIA0KPiB0cmlja3kgdW5mb3J0dW5hdGVseS4NCj4NCj4NCj4gQW0gbm93 IGV2ZW4gbW9yZSB3b3JyaWVkIHRoYW4gd2hlbiBJIHNlbnQgdGhlIGZpcnN0IGVtYWlsIC0g aWYgdGhhdCANCj4gMTglIGlzIGFjY3VyYXRlIHRoZW4gSSBhbSBnb2luZyB0byBiZSBkb2lu ZyB0aGlzIGFnYWluIGluIGFub3RoZXIgNCANCj4gbW9udGhzLCBhbmQgdGhhdHMgbm90IHN1 c3RhaW5hYmxlLiBJdCBhbHNvIGxvb2tzIGFzIGlmIHRoaXMgcHJvYmxlbSANCj4gaGFzIGdv dCBhIGxvdCB3b3JzZSByZWNlbnRseS4gVGhvdWdoIEkgd2FzbnQgbG9va2luZyBhdCB0aGUg bnVtYmVycyANCj4gYmVmb3JlLCBvbmx5IG5vdGljaW5nIHR5aGUgZmFpbHVyc2VzLiBJZiBJ IGxvb2sgYXQgJ1BlcmNlbnRhZ2UgVXNlZCANCj4gRW5kdXJhbmNlIEluZGljYXRvcicgaXNu dGVhZCBvZiB0aGUgJ1BlcmNlbnRfTGlmZXRpbWVfUmVtYWluJyB2YWx1ZSANCj4gdGhlbiBJ IHNlZSBzb21lIG9mIHRob3NlIHdlbGwgb3ZlciAyMDAlLiBUaGF0IHZhbHVlIGlzLCBvbiB0 aGUgbmV3ZXIgDQo+IGRyaXZlcywgMTAwIG1pbnVzIHRoZSAnUGVyY2VudF9MaWZldGltZV9S ZW1haW4nIHZhbHVlLCBzbyBJIGd1ZXNzIHRoZXkgDQo+IGFodmUgdGhlIHNhbWUgdW5kZXJs eWluZyBtZXRyaWMuDQo+DQo+IEkgZGlkbnQgbWVudGlvbiBpbiBteSBvcmlnaW5hbCBlbWFp bCwgYnV0IEkgYW0gZW5jcnlwdGluZyB0aGVzZSB3aXRoIA0KPiBnZWxpLiBEb2VzIGdlbGkg ZG8gYW55IHdyaXRlIGFtcGxpZmljYXRpb24gYXQgYWxsID8gVGhhdCBtaWdodCBleHBsYWlu IA0KPiB0aGUgaGlnaCB3cml0ZSB2b2x1bWVzLi4uDQo+DQo+IC1wZXRlLg0KPg0KQXMgbm90 ZWQgZWxzZXdoZXJlIGFzc3VtaW5nIGFzaGlmdD0xMiB0aGUgYW5zd2VyIG9uIHdyaXRlIGFt cGxpZmljYXRpb24gDQppcyBuby4NCg0KR2VsaSBzaG91bGQgYmUgaW5pdGlhbGl6ZWQgd2l0 aCAtcyA0MDk2OyBJJ20gYXNzdW1pbmcgeW91IGRpZCB0aGF0Pw0KDQpJIGhhdmUgYSA1LXVu aXQgZ2VsaS1lbmNyeXB0ZWQgcm9vdCBwb29sLCBhbGwgSW50ZWwgMjQwZ2IgU1NEcy4gVGhl eSBkbyANCm5vdCByZXBvcnQgcmVtYWluaW5nIGxpZmV0aW1lIHZpYSBzbWFydCBidXQgZG8g cmVwb3J0IGluZGljYXRpb25zIG9mIA0KdHJvdWJsZS7CoCBIZXJlJ3Mgb25lIGV4YW1wbGUg c25pcHBldCBmcm9tIG9uZSBvZiB0aGUgZHJpdmVzIGluIHRoYXQgcG9vbDoNCg0KU01BUlQg QXR0cmlidXRlcyBEYXRhIFN0cnVjdHVyZSByZXZpc2lvbiBudW1iZXI6IDENClZlbmRvciBT cGVjaWZpYyBTTUFSVCBBdHRyaWJ1dGVzIHdpdGggVGhyZXNob2xkczoNCklEIyBBVFRSSUJV VEVfTkFNRcKgwqDCoMKgwqDCoMKgwqDCoCBGTEFHU8KgwqDCoCBWQUxVRSBXT1JTVCBUSFJF U0ggRkFJTCBSQVdfVkFMVUUNCiDCoCA1IFJlYWxsb2NhdGVkX1NlY3Rvcl9DdMKgwqAgLU8t LUNLwqDCoCAwOTjCoMKgIDA5OMKgwqAgMDAwwqDCoMKgIC3CoMKgwqAgMA0KIMKgIDkgUG93 ZXJfT25fSG91cnPCoMKgwqDCoMKgwqDCoMKgwqAgLU8tLUNLwqDCoCAxMDDCoMKgIDEwMMKg wqAgMDAwwqDCoMKgIC0gNTMyNjQNCiDCoDEyIFBvd2VyX0N5Y2xlX0NvdW50wqDCoMKgwqDC oMKgIC1PLS1DS8KgwqAgMTAwwqDCoCAxMDDCoMKgIDAwMMKgwqDCoCAtwqDCoMKgIDEwMA0K MTcwIEF2YWlsYWJsZV9SZXNlcnZkX1NwYWNlIFBPLS1DS8KgwqAgMTAwwqDCoCAxMDDCoMKg IDAxMMKgwqDCoCAtwqDCoMKgIDANCjE3MSBQcm9ncmFtX0ZhaWxfQ291bnTCoMKgwqDCoMKg IC1PLS1DS8KgwqAgMTAwwqDCoCAxMDDCoMKgIDAwMMKgwqDCoCAtwqDCoMKgIDANCjE3MiBF cmFzZV9GYWlsX0NvdW50wqDCoMKgwqDCoMKgwqAgLU8tLUNLwqDCoCAxMDDCoMKgIDEwMMKg wqAgMDAwwqDCoMKgIC3CoMKgwqAgMA0KMTc0IFVuc2FmZV9TaHV0ZG93bl9Db3VudMKgwqAg LU8tLUNLwqDCoCAxMDDCoMKgIDEwMMKgwqAgMDAwwqDCoMKgIC3CoMKgwqAgNDENCjE3NSBQ b3dlcl9Mb3NzX0NhcF9UZXN0wqDCoMKgwqAgUE8tLUNLwqDCoCAxMDDCoMKgIDEwMMKgwqAg MDEwwqDCoMKgIC3CoMKgwqAgNjMxICgyOTUgNTQ0MikNCjE4MyBTQVRBX0Rvd25zaGlmdF9D b3VudMKgwqDCoCAtTy0tQ0vCoMKgIDEwMMKgwqAgMTAwwqDCoCAwMDDCoMKgwqAgLcKgwqDC oCAwDQoxODQgRW5kLXRvLUVuZF9FcnJvcsKgwqDCoMKgwqDCoMKgIFBPLS1DS8KgwqAgMTAw wqDCoCAxMDDCoMKgIDA5MMKgwqDCoCAtwqDCoMKgIDANCjE4NyBSZXBvcnRlZF9VbmNvcnJl Y3TCoMKgwqDCoMKgIC1PLS1DS8KgwqAgMTAwwqDCoCAxMDDCoMKgIDAwMMKgwqDCoCAtwqDC oMKgIDANCjE5MCBUZW1wZXJhdHVyZV9DYXNlwqDCoMKgwqDCoMKgwqAgLU8tLS1LwqDCoCAw NjjCoMKgIDA2M8KgwqAgMDAwwqDCoMKgIC3CoMKgwqAgMzIgKE1pbi9NYXggDQoyOS8zNykN CjE5MiBVbnNhZmVfU2h1dGRvd25fQ291bnTCoMKgIC1PLS1DS8KgwqAgMTAwwqDCoCAxMDDC oMKgIDAwMMKgwqDCoCAtwqDCoMKgIDQxDQoxOTQgVGVtcGVyYXR1cmVfSW50ZXJuYWzCoMKg wqAgLU8tLS1LwqDCoCAxMDDCoMKgIDEwMMKgwqAgMDAwwqDCoMKgIC3CoMKgwqAgMzINCjE5 NyBDdXJyZW50X1BlbmRpbmdfU2VjdG9ywqAgLU8tLUNLwqDCoCAxMDDCoMKgIDEwMMKgwqAg MDAwwqDCoMKgIC3CoMKgwqAgMA0KMTk5IENSQ19FcnJvcl9Db3VudMKgwqDCoMKgwqDCoMKg wqAgLU9TUkNLwqDCoCAxMDDCoMKgIDEwMMKgwqAgMDAwwqDCoMKgIC3CoMKgwqAgMA0KMjI1 IEhvc3RfV3JpdGVzXzMyTWlCwqDCoMKgwqDCoMKgIC1PLS1DS8KgwqAgMTAwwqDCoCAxMDDC oMKgIDAwMMKgwqDCoCAtIDE4MTE1NDgNCjIyNiBXb3JrbGRfTWVkaWFfV2Vhcl9JbmRpYyAt Ty0tQ0vCoMKgIDEwMMKgwqAgMTAwwqDCoCAwMDDCoMKgwqAgLcKgwqDCoCAyMDUNCjIyNyBX b3JrbGRfSG9zdF9SZWFkc19QZXJjwqAgLU8tLUNLwqDCoCAxMDDCoMKgIDEwMMKgwqAgMDAw wqDCoMKgIC3CoMKgwqAgNDkNCjIyOCBXb3JrbG9hZF9NaW51dGVzwqDCoMKgwqDCoMKgwqAg LU8tLUNLwqDCoCAxMDDCoMKgIDEwMMKgwqAgMDAwwqDCoMKgIC0gNTU4NDENCjIzMiBBdmFp bGFibGVfUmVzZXJ2ZF9TcGFjZSBQTy0tQ0vCoMKgIDEwMMKgwqAgMTAwwqDCoCAwMTDCoMKg wqAgLcKgwqDCoCAwDQoyMzMgTWVkaWFfV2Vhcm91dF9JbmRpY2F0b3IgLU8tLUNLwqDCoCAw ODnCoMKgIDA4OcKgwqAgMDAwwqDCoMKgIC3CoMKgwqAgMA0KMjM0IFRoZXJtYWxfVGhyb3R0 bGXCoMKgwqDCoMKgwqDCoCAtTy0tQ0vCoMKgIDEwMMKgwqAgMTAwwqDCoCAwMDDCoMKgwqAg LcKgwqDCoCAwLzANCjI0MSBIb3N0X1dyaXRlc18zMk1pQsKgwqDCoMKgwqDCoCAtTy0tQ0vC oMKgIDEwMMKgwqAgMTAwwqDCoCAwMDDCoMKgwqAgLSAxODExNTQ4DQoyNDIgSG9zdF9SZWFk c18zMk1pQsKgwqDCoMKgwqDCoMKgIC1PLS1DS8KgwqAgMTAwwqDCoCAxMDDCoMKgIDAwMMKg wqDCoCAtIDE0MjMyMTcNCiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqAgfHx8fHx8XyBLIGF1dG8ta2VlcA0KIMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8fHx8fF9fIEMgZXZl bnQgY291bnQNCiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqAgfHx8fF9fXyBSIGVycm9yIHJhdGUNCiDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfHx8X19fXyBTIHNwZWVkL3Bl cmZvcm1hbmNlDQogwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgIHx8X19fX18gTyB1cGRhdGVkIG9ubGluZQ0KIMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8X19fX19fIFAgcHJl ZmFpbHVyZSB3YXJuaW5nDQoNCg0KRGV2aWNlIFN0YXRpc3RpY3MgKEdQIExvZyAweDA0KQ0K UGFnZcKgIE9mZnNldCBTaXplwqDCoMKgwqDCoMKgwqAgVmFsdWUgRmxhZ3MgRGVzY3JpcHRp b24NCjB4MDHCoCA9PT09PcKgID3CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgID3CoCA9 PT3CoCA9PSBHZW5lcmFsIFN0YXRpc3RpY3MgKHJldiAyKSA9PQ0KMHgwMcKgIDB4MDA4wqAg NMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAxMDDCoCAtLS3CoCBMaWZldGltZSBQb3dlci1P biBSZXNldHMNCjB4MDHCoCAweDAxOMKgIDbCoMKgwqAgMTE4NzIyMTQ4MTAywqAgLS0twqAg TG9naWNhbCBTZWN0b3JzIFdyaXR0ZW4NCjB4MDHCoCAweDAyMMKgIDbCoMKgwqDCoMKgwqDC oCA4OTAzMzg5NcKgIC0tLcKgIE51bWJlciBvZiBXcml0ZSBDb21tYW5kcw0KMHgwMcKgIDB4 MDI4wqAgNsKgwqDCoMKgIDkzMjcxOTUxOTA5wqAgLS0twqAgTG9naWNhbCBTZWN0b3JzIFJl YWQNCjB4MDHCoCAweDAzMMKgIDbCoMKgwqDCoMKgwqDCoMKgIDY3OTc5OTDCoCAtLS3CoCBO dW1iZXIgb2YgUmVhZCBDb21tYW5kcw0KDQo2IHllYXJzIGluLXVzZSwgcm91Z2hseSwgYW5k IG5vIGluZGljYXRpb24gb2YgYW55dGhpbmcgZ29pbmcgb24gaW4gdGVybXMgDQpvZiB3YXJu aW5ncyBhYm91dCB1dGlsaXphdGlvbiBvciB3ZWFyLW91dC7CoCBUaGVyZSBpcyBhIE1ZU1FM IGRhdGFiYXNlIG9uIA0KdGhpcyBib3ggdXNlZCBieSBDYWN0aSB0aGF0IGlzIHJ1bm5pbmcg YWxsIHRoZSB0aW1lIGFuZCB3aGlsZSB0aGUgDQp0cmFmZmljIGlzIHJlYWwgaGlnaCwgaXQn cyB0aGVyZSAodGhlcmUgaXMgYWxzbyBhIFBvc3RncmVzIHNlcnZlciANCnJ1bm5pbmcgb24g dGhlcmUgdGhhdCBzZWVzIHNvbWUgdHJhZmZpYyB0b28uKcKgIFRoZXNlIHNwZWNpZmljIGRy aXZlcyANCndlcmUgc2VsZWN0ZWQgZHVlIHRvIGhhdmluZyBwb3dlci1mYWlsIHByb3RlY3Rp b24gZm9yIGRhdGEgaW4tZmxpZ2h0IC0tIA0KdGhleSB3ZXJlIG9uZSBvZiBvbmx5IGEgZmV3 IHRoYXQgSSd2ZSB0ZXN0ZWQgd2hpY2ggcGFzc2VkIGEgInB1bGwgdGhlIA0KY29yZCIgdGVz dCBldmVuIHRob3VnaCB0aGV5J3JlIGFjdHVhbGx5IHRoZSA3MzBzLCBOT1QgdGhlICJEQyIg c2VyaWVzLg0KDQpSYWlkejIgY29uZmlndXJhdGlvbjoNCg0Kcm9vdEBOZXdGUzovaG9tZS9r YXJsICMgenBvb2wgc3RhdHVzIHpzcg0KIMKgIHBvb2w6IHpzcg0KIMKgc3RhdGU6IE9OTElO RQ0KIMKgIHNjYW46IHNjcnViIHJlcGFpcmVkIDAgaW4gMCBkYXlzIDAwOjA3OjA1IHdpdGgg MCBlcnJvcnMgb24gTW9uIEp1biAyOCANCjAzOjQzOjU4IDIwMjENCmNvbmZpZzoNCg0KIMKg wqDCoMKgwqDCoMKgIE5BTUXCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIFNUQVRFwqDCoMKgwqAg UkVBRCBXUklURSBDS1NVTQ0KIMKgwqDCoMKgwqDCoMKgIHpzcsKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoCBPTkxJTkXCoMKgwqDCoMKgwqAgMMKgwqDCoMKgIDDCoMKgwqDCoCAwDQogwqDC oMKgwqDCoMKgwqDCoMKgIHJhaWR6Mi0wwqDCoMKgwqDCoCBPTkxJTkXCoMKgwqDCoMKgwqAg MMKgwqDCoMKgIDDCoMKgwqDCoCAwDQogwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBhZGEwcDQu ZWxpwqAgT05MSU5FwqDCoMKgwqDCoMKgIDDCoMKgwqDCoCAwwqDCoMKgwqAgMA0KIMKgwqDC oMKgwqDCoMKgwqDCoMKgwqAgYWRhMXA0LmVsacKgIE9OTElORcKgwqDCoMKgwqDCoCAwwqDC oMKgwqAgMMKgwqDCoMKgIDANCiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIGFkYTJwNC5lbGnC oCBPTkxJTkXCoMKgwqDCoMKgwqAgMMKgwqDCoMKgIDDCoMKgwqDCoCAwDQogwqDCoMKgwqDC oMKgwqDCoMKgwqDCoCBhZGEzcDQuZWxpwqAgT05MSU5FwqDCoMKgwqDCoMKgIDDCoMKgwqDC oCAwwqDCoMKgwqAgMA0KIMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgYWRhNHA0LmVsacKgIE9O TElORcKgwqDCoMKgwqDCoCAwwqDCoMKgwqAgMMKgwqDCoMKgIDANCg0KZXJyb3JzOiBObyBr bm93biBkYXRhIGVycm9ycw0KDQpNaWNyb24gYXBwZWFycyB0byBiZSB0aGUgb25seSBwZW9w bGUgbWFraW5nIHN1aXRhYmxlIHJlcGxhY2VtZW50cyBpZiBhbmQgDQp3aGVuIHRoZXNlIGRv IHN0YXJ0IHRvIGZhaWwgb24gbWUsIGJ1dCBmcm9tIHdoYXQgSSBzZWUgaGVyZSBpdCB3aWxs IGJlIGEgDQpnb29kIHdoaWxlIHlldC4NCg0KLS0NCi0tIA0KS2FybCBEZW5uaW5nZXINCmth cmxAZGVubmluZ2VyLm5ldCA8bWFpbHRvOmthcmxAZGVubmluZ2VyLm5ldD4NCi9UaGUgTWFy a2V0IFRpY2tlci8NCi9bUy9NSU1FIGVuY3J5cHRlZCBlbWFpbCBwcmVmZXJyZWRdLw0K --------------51B6809D4511225383F7526E-- --------------ms030403050202080209050209 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC DdgwggagMIIEiKADAgECAhMA5EiKghDOXrvfxYxjITXYDdhIMA0GCSqGSIb3DQEBCwUAMIGL MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJTmljZXZpbGxlMRkw FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExITAf BgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQTAeFw0xNzA4MTcxNjQyMTdaFw0yNzA4 MTUxNjQyMTdaMHsxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkwFwYDVQQKDBBD dWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExJTAjBgNVBAMMHEN1 ZGEgU3lzdGVtcyBMTEMgMjAxNyBJbnQgQ0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQC1aJotNUI+W4jP7xQDO8L/b4XiF4Rss9O0B+3vMH7Njk85fZ052QhZpMVlpaaO+sCI KqG3oNEbuOHzJB/NDJFnqh7ijBwhdWutdsq23Ux6TvxgakyMPpT6TRNEJzcBVQA0kpby1DVD 0EKSK/FrWWBiFmSxg7qUfmIq/mMzgE6epHktyRM3OGq3dbRdOUgfumWrqHXOrdJz06xE9NzY vc9toqZnd79FUtE/nSZVm1VS3Grq7RKV65onvX3QOW4W1ldEHwggaZxgWGNiR/D4eosAGFxn uYeWlKEC70c99Mp1giWux+7ur6hc2E+AaTGh+fGeijO5q40OGd+dNMgK8Es0nDRw81lRcl24 SWUEky9y8DArgIFlRd6d3ZYwgc1DMTWkTavx3ZpASp5TWih6yI8ACwboTvlUYeooMsPtNa9E 6UQ1nt7VEi5syjxnDltbEFoLYcXBcqhRhFETJe9CdenItAHAtOya3w5+fmC2j/xJz29og1KH YqWHlo3Kswi9G77an+zh6nWkMuHs+03DU8DaOEWzZEav3lVD4u76bKRDTbhh0bMAk4eXriGL h4MUoX3Imfcr6JoyheVrAdHDL/BixbMH1UUspeRuqQMQ5b2T6pabXP0oOB4FqldWiDgJBGRd zWLgCYG8wPGJGYgHibl5rFiI5Ix3FQncipc6SdUzOQIDAQABo4IBCjCCAQYwHQYDVR0OBBYE FF3AXsKnjdPND5+bxVECGKtc047PMIHABgNVHSMEgbgwgbWAFBu1oRhUMNEzjODolDka5k4Q EDBioYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJ TmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5 c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYIJAKxAy1WBo2kY MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3DQEBCwUAA4IC AQCB5686UCBVIT52jO3sz9pKuhxuC2npi8ZvoBwt/IH9piPA15/CGF1XeXUdu2qmhOjHkVLN gO7XB1G8CuluxofOIUce0aZGyB+vZ1ylHXlMeB0R82f5dz3/T7RQso55Y2Vog2Zb7PYTC5B9 oNy3ylsnNLzanYlcW3AAfzZcbxYuAdnuq0Im3EpGm8DoItUcf1pDezugKm/yKtNtY6sDyENj tExZ377cYA3IdIwqn1Mh4OAT/Rmh8au2rZAo0+bMYBy9C11Ex0hQ8zWcvPZBDn4v4RtO8g+K uQZQcJnO09LJNtw94W3d2mj4a7XrsKMnZKvm6W9BJIQ4Nmht4wXAtPQ1xA+QpxPTmsGAU0Cv HmqVC7XC3qxFhaOrD2dsvOAK6Sn3MEpH/YrfYCX7a7cz5zW3DsJQ6o3pYfnnQz+hnwLlz4MK 17NIA0WOdAF9IbtQqarf44+PEyUbKtz1r0KGeGLs+VGdd2FLA0e7yuzxJDYcaBTVwqaHhU2/ Fna/jGU7BhrKHtJbb/XlLeFJ24yvuiYKpYWQSSyZu1R/gvZjHeGb344jGBsZdCDrdxtQQcVA 6OxsMAPSUPMrlg9LWELEEYnVulQJerWxpUecGH92O06wwmPgykkz//UmmgjVSh7ErNvL0lUY UMfunYVO/O5hwhW+P4gviCXzBFeTtDZH259O7TCCBzAwggUYoAMCAQICEwCg0WvVwekjGFiO 62SckFwepz0wDQYJKoZIhvcNAQELBQAwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3Jp ZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBD QTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExMQyAyMDE3IEludCBDQTAeFw0xNzA4MTcyMTIx MjBaFw0yMjA4MTYyMTIxMjBaMFcxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkw FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRswGQYDVQQDDBJrYXJsQGRlbm5pbmdlci5uZXQw ggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQC+HVSyxVtJhy3Ohs+PAGRuO//Dha9A 16l5FPATr6wude9zjX5f2lrkRyU8vhCXTZW7WbvWZKpcZ8r0dtZmiK9uF58Ec6hhvfkxJzbg 96WHBw5Fumd5ahZzuCJDtCAWW8R7/KN+zwzQf1+B3MVLmbaXAFBuKzySKhKMcHbK3/wjUYTg y+3UK6v2SBrowvkUBC+jxNg3Wy12GsTXcUS/8FYIXgVVPgfZZrbJJb5HWOQpvvhILpPCD3xs YJFNKEPltXKWHT7Qtc2HNqikgNwj8oqOb+PeZGMiWapsatKm8mxuOOGOEBhAoTVTwUHlMNTg 6QUCJtuWFCK38qOCyk9Haj+86lUU8RG6FkRXWgMbNQm1mWREQhw3axgGLSntjjnznJr5vsvX SYR6c+XKLd5KQZcS6LL8FHYNjqVKHBYM+hDnrTZMqa20JLAF1YagutDiMRURU23iWS7bA9tM cXcqkclTSDtFtxahRifXRI7Epq2GSKuEXe/1Tfb5CE8QsbCpGsfSwv2tZ/SpqVG08MdRiXxN 5tmZiQWo15IyWoeKOXl/hKxA9KPuDHngXX022b1ly+5ZOZbxBAZZMod4y4b4FiRUhRI97r9l CxsP/EPHuuTIZ82BYhrhbtab8HuRo2ofne2TfAWY2BlA7ExM8XShMd9bRPZrNTokPQPUCWCg CdIATQIDAQABo4IBzzCCAcswPAYIKwYBBQUHAQEEMDAuMCwGCCsGAQUFBzABhiBodHRwOi8v b2NzcC5jdWRhc3lzdGVtcy5uZXQ6ODg4ODAJBgNVHRMEAjAAMBEGCWCGSAGG+EIBAQQEAwIF oDAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMDMGCWCG SAGG+EIBDQQmFiRPcGVuU1NMIEdlbmVyYXRlZCBDbGllbnQgQ2VydGlmaWNhdGUwHQYDVR0O BBYEFLElmNWeVgsBPe7O8NiBzjvjYnpRMIHKBgNVHSMEgcIwgb+AFF3AXsKnjdPND5+bxVEC GKtc047PoYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UE BwwJTmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRh IFN5c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYITAORIioIQ zl6738WMYyE12A3YSDAdBgNVHREEFjAUgRJrYXJsQGRlbm5pbmdlci5uZXQwDQYJKoZIhvcN AQELBQADggIBAJXboPFBMLMtaiUt4KEtJCXlHO/3ZzIUIw/eobWFMdhe7M4+0u3te0sr77QR dcPKR0UeHffvpth2Mb3h28WfN0FmJmLwJk+pOx4u6uO3O0E1jNXoKh8fVcL4KU79oEQyYkbu 2HwbXBU9HbldPOOZDnPLi0whi/sbFHdyd4/w/NmnPgzAsQNZ2BYT9uBNr+jZw4SsluQzXG1X lFL/qCBoi1N2mqKPIepfGYF6drbr1RnXEJJsuD+NILLooTNf7PMgHPZ4VSWQXLNeFfygoOOK FiO0qfxPKpDMA+FHa8yNjAJZAgdJX5Mm1kbqipvb+r/H1UAmrzGMbhmf1gConsT5f8KU4n3Q IM2sOpTQe7BoVKlQM/fpQi6aBzu67M1iF1WtODpa5QUPvj1etaK+R3eYBzi4DIbCIWst8MdA 1+fEeKJFvMEZQONpkCwrJ+tJEuGQmjoQZgK1HeloepF0WDcviiho5FlgtAij+iBPtwMuuLiL shAXA5afMX1hYM4l11JXntle12EQFP1r6wOUkpOdxceCcMVDEJBBCHW2ZmdEaXgAm1VU+fnQ qS/wNw/S0X3RJT1qjr5uVlp2Y0auG/eG0jy6TT0KzTJeR9tLSDXprYkN2l/Qf7/nT6Q03qyE QnnKiBXWAZXveafyU/zYa7t3PTWFQGgWoC4w6XqgPo4KV44OMYIFBzCCBQMCAQEwgZIwezEL MAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBM TEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExM QyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTANBglghkgBZQMEAgMFAKCCAkUw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjEwNzA1MTUwOTM3 WjBPBgkqhkiG9w0BCQQxQgRAO5eZVgs7dmutVcENQjTrmDvZ1pDtoIJOmT4OjRv1sOTYNxks 1nSin4FHY8CWTmgooxpHOGvHoYeNYTwrPtMHHzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFl AwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3 DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGjBgkrBgEEAYI3EAQxgZUwgZIwezEL MAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBM TEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExM QyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTCBpQYLKoZIhvcNAQkQAgsxgZWg gZIwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lz dGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0 ZW1zIExMQyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTANBgkqhkiG9w0BAQEF AASCAgAKpb1goEZ7+J9YlE5VlI8+cCedmJ5c46N+bkLAhuoEVlNV9q42wGZjUkFFeL6BX1lP aU1y82Dp+qBK88Ei95FZeSNjZgRZrHmVz56a0x81osv2XSZ9+c5V3NKvG79rQodP38NpK8+w j1MPmKShvYSetEZPFGpHL1WBiqr5OWO3osBkkZPhqi8AWoYYprJz0LxtUH+yNROm2JsJsSbR DIkHkODsBMigV05AMQhbQuE7EWM5OXaH0sZCrPMpP2F0r/RcchT0yLc5e4R+yNgqfGXh3Zir GG+wqNWBo5Bi7kUbR186UFc8C3f7T1FO6C/BeJMMMltIz1V5Sjs0nbdh1bMGuGmJM3VUUOn+ VYzVN3FF8E7hU9MigSDTA7qoyMhQsYX59U+v6h+usfv79G/gHDbWoEvbS2fo3inzsk+/iWZB zZF+hkmIRhMrYcuRiiQc/Tlv03WlXEt/K2RvXoQROlGNIHhSerxUMICvjZnFNLHGwgTkXoMj 91u5qmERryoxpahE0D11SuU96H5A6yw9VSeCS35XuCxgTISSy8onEyf6Q+fc6NpUYpMAI5vG lQeAlrL+ZWo1tj5sGYyDzoSH8u2iPCCqHlWAIgG5f7i/79gOeKfOj+oyX+nDAxhLsTXSa7J1 uoL1N4IAAC4fjyOW3UEQTTG2wJcdlvOo626+ddNWqQAAAAAAAA== --------------ms030403050202080209050209-- From nobody Mon Jul 5 15:29:00 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 B4DAF11DB66A for ; Mon, 5 Jul 2021 15:29:02 +0000 (UTC) (envelope-from petefrench@ingresso.co.uk) Received: from constantine.ingresso.co.uk (constantine.ingresso.co.uk [IPv6:2001:470:6a18:411::3]) (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 4GJV324s6Sz4Wyp; Mon, 5 Jul 2021 15:29:02 +0000 (UTC) (envelope-from petefrench@ingresso.co.uk) Received: from [2001:470:6cc4:1:cd6:5836:ddba:7b54] (helo=balta.drayhouse.twisted.org.uk) by constantine.ingresso.co.uk with esmtpsa (TLS1.3) tls TLS_AES_128_GCM_SHA256 (Exim 4.94.2 (FreeBSD)) (envelope-from ) id 1m0QWr-000Npx-Do; Mon, 05 Jul 2021 15:29:01 +0000 Subject: Re: ZFS + mysql appears to be killing my SSD's To: Alan Somers Cc: Stefan Esser , FreeBSD Stable Mailing List References: <89c37c3e-22e8-006e-5826-33bd7db7739e@ingresso.co.uk> <2fd9b7e4-dc75-fedc-28d7-b98191167e6b@freebsd.org> <9c71d627-55b8-2464-6cc9-489e4ce98049@ingresso.co.uk> From: Pete French Message-ID: Date: Mon, 5 Jul 2021 16:29:00 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 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 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4GJV324s6Sz4Wyp X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: N On 05/07/2021 15:51, Alan Somers wrote: > If you're using 4K sectors anyway, then GELI does not create any extra > write amplification.   But if you're extra paranoid and you use the "-T" > option to "geli attach", then GELI will block TRIM commands.  That could > hurt SSD lifetime.  But I don't think "-T" is the default.  You are > using 4K sectors, right?  ZFS's ashift is set to 12? > -Alan Yup, 4k sectors, and I initialised geli telling it to present as 4k sectors. Am glad to hear that it wont amplify writes - thats what I assumed, but nice to have it confirmed. -pete. From nobody Mon Jul 5 15:37:03 2021 X-Original-To: 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 CB06511DE22F for ; Mon, 5 Jul 2021 15:40:26 +0000 (UTC) (envelope-from lysfjord.daniel@smokepit.net) Received: from smtp-out.smokepit.net (smtp-out.smokepit.net [18.200.56.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp-out.smokepit.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GJVJ94ZGnz4Zjn for ; Mon, 5 Jul 2021 15:40:25 +0000 (UTC) (envelope-from lysfjord.daniel@smokepit.net) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=smokepit.net; s=loke; h=References:In-Reply-To:To:Subject:Message-ID:From: Content-Transfer-Encoding:Content-Type:Date:MIME-Version:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=g7wO2KupEGtQsAs5DXHauyVZ5SSge/IrCHiV4XiIp8I=; b=wvCVkHolHkPfNZpdBLwmYisMSO i8P0i8/DbFOV5OuuRFfvnr2XMiWdy5la60atc7sWC1nGI+pUvWYGsJUurc6acKdQVJ8rHuNzEUihy hsZpn/7ZyZrctXRXAu/SEbTMQ7XZ4TEoNdYzNyeNdzZobPAU0VSWuuMyMA3S5Ts4K3L0=; Received: from cm-84.215.43.250.getinternet.no ([84.215.43.250] helo=smokepit.net) by smtp-out.smokepit.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m0Qhm-0006qh-2A for stable@freebsd.org; Mon, 05 Jul 2021 15:40:18 +0000 Received: from http01.lan.smokepit.net ([10.0.3.111] helo=webmail.smokepit.net) by smokepit.net with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2 (FreeBSD)) (envelope-from ) id 1m0Qed-000B2f-Lv for stable@freebsd.org; Mon, 05 Jul 2021 17:37:04 +0200 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 Date: Mon, 05 Jul 2021 15:37:03 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: RainLoop/1.15.0 Message-ID: <5ff412bc5b0d1f83284895911456ee97@smokepit.net> Subject: Re: ZFS + mysql appears to be killing my SSD's To: stable@freebsd.org In-Reply-To: References: <89c37c3e-22e8-006e-5826-33bd7db7739e@ingresso.co.uk> <2fd9b7e4-dc75-fedc-28d7-b98191167e6b@freebsd.org> <9c71d627-55b8-2464-6cc9-489e4ce98049@ingresso.co.uk> X-Originating-IP: 10.0.0.200 X-Spam-Report: Action: no action Symbol: ARC_NA(0.00) Symbol: RCVD_VIA_SMTP_AUTH(0.00) Symbol: HAS_XOIP(0.00) Symbol: FROM_HAS_DN(0.00) Symbol: TO_MATCH_ENVRCPT_ALL(0.00) Symbol: BAYES_HAM(-3.00) Symbol: MIME_GOOD(-0.10) Symbol: TO_DN_NONE(0.00) Symbol: RCPT_COUNT_ONE(0.00) Symbol: RCVD_COUNT_ONE(0.00) Symbol: FROM_EQ_ENVFROM(0.00) Symbol: MIME_TRACE(0.00) Symbol: RCVD_TLS_ALL(0.00) Symbol: MID_RHS_MATCH_FROM(0.00) Message-ID: 5ff412bc5b0d1f83284895911456ee97@smokepit.net X-Rspamd-Queue-Id: 4GJVJ94ZGnz4Zjn X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=smokepit.net header.s=loke header.b=wvCVkHol; dmarc=pass (policy=reject) header.from=smokepit.net; spf=pass (mx1.freebsd.org: domain of lysfjord.daniel@smokepit.net designates 18.200.56.156 as permitted sender) smtp.mailfrom=lysfjord.daniel@smokepit.net X-Spamd-Result: default: False [-3.90 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[smokepit.net:s=loke]; HAS_XOIP(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-0.90)[-0.901]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[18.200.56.156:from:127.0.2.255]; RCVD_COUNT_THREE(0.00)[3]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_SPF_ALLOW(-0.20)[+ip4:18.200.56.156]; DKIM_TRACE(0.00)[smokepit.net:+]; DMARC_POLICY_ALLOW(-0.50)[smokepit.net,reject]; NEURAL_HAM_SHORT(-1.00)[-0.998]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[18.200.56.156:from]; ASN(0.00)[asn:16509, ipnet:18.200.0.0/16, country:US]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[stable]; RECEIVED_SPAMHAUS_PBL(0.00)[84.215.43.250:received] Reply-To: lysfjord.daniel@smokepit.net From: Daniel Lysfjord via stable X-Original-From: Daniel Lysfjord X-ThisMailContainsUnwantedMimeParts: N "Karl Denninger" skrev 5. juli 2021 kl. 17:10: > On 7/5/2021 10:30, Pete French wrote: >=20 >>=20On 05/07/2021 14:37, Stefan Esser wrote: >>> Hi Pete, >>>=20 >>>=20have you checked the drive state and statistics with smartctl? >>=20 >>=20Hi, thanks for the reply - yes, I did check the statistics, and they >> dont make a lot of sense. I was just looking at them again in fact. >>=20 >>=20So, one of the machines that we chnaged a drive on when this first >> started, which was 4 weeks ago. >>=20 >>=20root@telehouse04:/home/webadmin # smartctl -a /dev/ada0 | grep Perc >> 169 Remaining_Lifetime_Perc 0x0000 082 082 000 Old_age >> Offline - 82 >> root@telehouse04:/home/webadmin # smartctl -a /dev/ada1 | grep Perc >> 202 Percent_Lifetime_Remain 0x0030 100 100 001 Old_age >> Offline - 0 >>=20 >>=20Now, from that you might think the 2nd drive was the one changes, bu= t >> no. Its the first one, which is now at 82% lifetime remaining! The >> other druve, still at 100%, has been in there a year. The drives are >> different manufacturers, which makes comparing most of the numbers >> tricky unfortunately. >>=20 >>=20Am now even more worried than when I sent the first email - if that >> 18% is accurate then I am going to be doing this again in another 4 >> months, and thats not sustainable. It also looks as if this problem >> has got a lot worse recently. Though I wasnt looking at the numbers >> before, only noticing tyhe failurses. If I look at 'Percentage Used >> Endurance Indicator' isntead of the 'Percent_Lifetime_Remain' value >> then I see some of those well over 200%. That value is, on the newer >> drives, 100 minus the 'Percent_Lifetime_Remain' value, so I guess they >> ahve the same underlying metric. >>=20 >>=20I didnt mention in my original email, but I am encrypting these with >> geli. Does geli do any write amplification at all ? That might explain >> the high write volumes... >>=20 >>=20-pete. >=20 >=20As noted elsewhere assuming ashift=3D12 the answer on write amplifica= tion > is no. >=20 >=20Geli should be initialized with -s 4096; I'm assuming you did that? >=20 >=20I have a 5-unit geli-encrypted root pool, all Intel 240gb SSDs. They = do > not report remaining lifetime via smart but do report indications of > trouble. Here's one example snippet from one of the drives in that poo= l: >=20 >=20SMART Attributes Data Structure revision number: 1 > Vendor Specific SMART Attributes with Thresholds: > ID# ATTRIBUTE_NAME FLAGS VALUE WORST THRESH FAIL RAW_VALUE > 5 Reallocated_Sector_Ct -O--CK 098 098 000 - 0 > 9 Power_On_Hours -O--CK 100 100 000 - 53264 > 12 Power_Cycle_Count -O--CK 100 100 000 - 100 > 170 Available_Reservd_Space PO--CK 100 100 010 - 0 > 171 Program_Fail_Count -O--CK 100 100 000 - 0 > 172 Erase_Fail_Count -O--CK 100 100 000 - 0 > 174 Unsafe_Shutdown_Count -O--CK 100 100 000 - 41 > 175 Power_Loss_Cap_Test PO--CK 100 100 010 - 631 (295 5= 442) > 183 SATA_Downshift_Count -O--CK 100 100 000 - 0 > 184 End-to-End_Error PO--CK 100 100 090 - 0 > 187 Reported_Uncorrect -O--CK 100 100 000 - 0 > 190 Temperature_Case -O---K 068 063 000 - 32 (Min/Ma= x > 29/37) > 192 Unsafe_Shutdown_Count -O--CK 100 100 000 - 41 > 194 Temperature_Internal -O---K 100 100 000 - 32 > 197 Current_Pending_Sector -O--CK 100 100 000 - 0 > 199 CRC_Error_Count -OSRCK 100 100 000 - 0 > 225 Host_Writes_32MiB -O--CK 100 100 000 - 1811548 > 226 Workld_Media_Wear_Indic -O--CK 100 100 000 - 205 > 227 Workld_Host_Reads_Perc -O--CK 100 100 000 - 49 > 228 Workload_Minutes -O--CK 100 100 000 - 55841 > 232 Available_Reservd_Space PO--CK 100 100 010 - 0 > 233 Media_Wearout_Indicator -O--CK 089 089 000 - 0 > 234 Thermal_Throttle -O--CK 100 100 000 - 0/0 > 241 Host_Writes_32MiB -O--CK 100 100 000 - 1811548 > 242 Host_Reads_32MiB -O--CK 100 100 000 - 1423217 > ||||||_ K auto-keep > |||||__ C event count > ||||___ R error rate > |||____ S speed/performance > ||_____ O updated online > |______ P prefailure warning >=20 >=20Device Statistics (GP Log 0x04) > Page Offset Size Value Flags Description > 0x01 =3D=3D=3D=3D=3D =3D =3D =3D=3D=3D =3D=3D General= Statistics (rev 2) =3D=3D > 0x01 0x008 4 100 --- Lifetime Power-On Resets > 0x01 0x018 6 118722148102 --- Logical Sectors Written > 0x01 0x020 6 89033895 --- Number of Write Commands > 0x01 0x028 6 93271951909 --- Logical Sectors Read > 0x01 0x030 6 6797990 --- Number of Read Commands >=20 >=206 years in-use, roughly, and no indication of anything going on in te= rms > of warnings about utilization or wear-out. There is a MYSQL database o= n > this box used by Cacti that is running all the time and while the > traffic is real high, it's there (there is also a Postgres server > running on there that sees some traffic too.) These specific drives > were selected due to having power-fail protection for data in-flight -- > they were one of only a few that I've tested which passed a "pull the > cord" test even though they're actually the 730s, NOT the "DC" series. >=20 >=20Raidz2 configuration: >=20 >=20root@NewFS:/home/karl # zpool status zsr > pool: zsr > state: ONLINE > scan: scrub repaired 0 in 0 days 00:07:05 with 0 errors on Mon Jun 28 > 03:43:58 2021 > config: >=20 >=20NAME STATE READ WRITE CKSUM > zsr ONLINE 0 0 0 > raidz2-0 ONLINE 0 0 0 > ada0p4.eli ONLINE 0 0 0 > ada1p4.eli ONLINE 0 0 0 > ada2p4.eli ONLINE 0 0 0 > ada3p4.eli ONLINE 0 0 0 > ada4p4.eli ONLINE 0 0 0 >=20 >=20errors: No known data errors >=20 >=20Micron appears to be the only people making suitable replacements if = and > when these do start to fail on me, but from what I see here it will be = a > good while yet. >=20 >=20-- > -- > Karl Denninger > karl@denninger.net > /The Market Ticker/ > /[S/MIME encrypted email preferred]/ Running MariaDB and PostgreSQL with FreeBSD 12.2 on a couple of Samsung 2= 50GB 960 EVO drives in a mirror. Very low usage, and expected amount of w= ear: smartctl snippet: SMART/Health Information (NVMe Log 0x02) Critical Warning: 0x00 Temperature: 42 Celsius Available Spare: 100% Available Spare Threshold: 10% Percentage Used: 1% Data Units Read: 5=C2=A0294=C2=A0592 [2,71 TB] Data Units Written: 25=C2=A0471=C2=A0775 [13,0 TB] Host Read Commands: 55=C2=A0763=C2=A0074 Host Write Commands: 1=C2=A0245=C2=A0546=C2=A0898 Controller Busy Time: 3=C2=A0290 Power Cycles: 81 Power On Hours: 29=C2=A0491 Unsafe Shutdowns: 46 Media and Data Integrity Errors: 0 Error Information Log Entries: 6 Warning Comp. Temperature Time: 0 Critical Comp. Temperature Time: 0 Temperature Sensor 1: 42 Celsius Temperature Sensor 2: 55 Celsius zpool status: pool: znvme state: ONLINE scan: scrub repaired 0 in 0 days 00:00:14 with 0 errors on Fri Jun 4 0= 3:03:46 2021 config: NAME STATE READ WRITE CKSUM znvme ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 nvd0 ONLINE 0 0 0 nvd1 ONLINE 0 0 0 errors: No known data errors From nobody Mon Jul 5 15:49:20 2021 X-Original-To: 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 960E97C8120 for ; Mon, 5 Jul 2021 15:49:23 +0000 (UTC) (envelope-from petefrench@ingresso.co.uk) Received: from constantine.ingresso.co.uk (constantine.ingresso.co.uk [IPv6:2001:470:6a18:411::3]) (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 4GJVVV5cj3z4cSs for ; Mon, 5 Jul 2021 15:49:22 +0000 (UTC) (envelope-from petefrench@ingresso.co.uk) Received: from [2001:470:6cc4:1:cd6:5836:ddba:7b54] (helo=balta.drayhouse.twisted.org.uk) by constantine.ingresso.co.uk with esmtpsa (TLS1.3) tls TLS_AES_128_GCM_SHA256 (Exim 4.94.2 (FreeBSD)) (envelope-from ) id 1m0QqX-000NrQ-28 for stable@freebsd.org; Mon, 05 Jul 2021 15:49:21 +0000 Subject: Re: ZFS + mysql appears to be killing my SSD's To: stable@freebsd.org References: <89c37c3e-22e8-006e-5826-33bd7db7739e@ingresso.co.uk> <2fd9b7e4-dc75-fedc-28d7-b98191167e6b@freebsd.org> <9c71d627-55b8-2464-6cc9-489e4ce98049@ingresso.co.uk> From: Pete French Message-ID: <4b5a0367-96c2-1d3f-bcb2-a76bd66bc76e@ingresso.co.uk> Date: Mon, 5 Jul 2021 16:49:20 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 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 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4GJVVV5cj3z4cSs X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=ingresso.co.uk; spf=pass (mx1.freebsd.org: domain of petefrench@ingresso.co.uk designates 2001:470:6a18:411::3 as permitted sender) smtp.mailfrom=petefrench@ingresso.co.uk X-Spamd-Result: default: False [-1.76 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[2001:470:6a18:411::3:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2001:470:6a18:411::3]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-0.93)[-0.930]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[2001:470:6a18:411::3:from:127.0.2.255]; NEURAL_HAM_MEDIUM(-0.99)[-0.990]; NEURAL_SPAM_SHORT(0.96)[0.962]; DMARC_POLICY_ALLOW(-0.50)[ingresso.co.uk,none]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[stable]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On 05/07/2021 16:09, Karl Denninger wrote: > As noted elsewhere assuming ashift=12 the answer on write amplification > is no. > > Geli should be initialized with -s 4096; I'm assuming you did that? Yup, I have everything defaulting to 4k sectors now, and I was hoping there was no write amplification going on if I did that. > I have a 5-unit geli-encrypted root pool, all Intel 240gb SSDs. They do > not report remaining lifetime via smart but do report indications of > trouble.  Here's one example snippet from one of the drives in that pool: Thanks for this ... its inyeresting to have something to compare against. Mine are Kingston 240G drives, though some of the replacements will be Crucial (i.e. Micron) > Device Statistics (GP Log 0x04) > Page  Offset Size        Value Flags Description > 0x01  =====  =               =  ===  == General Statistics (rev 2) == > 0x01  0x008  4             100  ---  Lifetime Power-On Resets > 0x01  0x018  6    118722148102  ---  Logical Sectors Written > 0x01  0x020  6        89033895  ---  Number of Write Commands > 0x01  0x028  6     93271951909  ---  Logical Sectors Read > 0x01  0x030  6         6797990  ---  Number of Read Commands So this is interesting, because my vaues for the machine I was describing arlier, where a drive was replaced are ada0:0x01 0x018 6 3084505072 --- Logical Sectors Written ada0:0x01 0x020 6 1219372767 --- Number of Write Commands ada0:0x01 0x028 6 1168765724 --- Logical Sectors Read ada0:0x01 0x030 6 56588781 --- Number of Read Commands ada1:0x01 0x018 6 2014784574 --- Logical Sectors Written ada1:0x01 0x020 6 68557083 --- Number of Write Commands ada1:0x01 0x028 6 41230034 --- Logical Sectors Read ada1:0x01 0x030 6 2438618 --- Number of Read Commands The replacement has more written sectors than the one which wasnt replaced. yet these are in RAID-1, so how can that be? The numbers for sectors written are way lower than yours, but the write commands are much higher. For a pair of drives in RAID-1 where ada0 has been replaced and resilvered from ada1, those looks very wrong to me. > 6 years in-use, roughly, and no indication of anything going on in terms > of warnings about utilization or wear-out.  There is a MYSQL database on yes, your figures are what I expect to see, but the ones above are what I actually have. The disparity between the two halves of the RAID are bothering me, I have to say. Do you have any tuning applies to your ZFS filesystems ? I have reduced the recrodsize on the data directories to 32k to better match innodb and have turned off atime and sync. But those are things I would expect to reduce the write load, not increase it. -pete. From nobody Tue Jul 6 23:01:25 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 7E8E611DC70C for ; Tue, 6 Jul 2021 23:01:37 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from mail.nomadlogic.org (mail.nomadlogic.org [66.165.241.226]) (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 "mail.nomadlogic.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GKJ2m3sLXz3jfP; Tue, 6 Jul 2021 23:01:36 +0000 (UTC) (envelope-from pete@nomadlogic.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nomadlogic.org; s=04242021; t=1625612487; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=7IBLG7ASEsWDl92bcSOFtJPQdTZVAbzg6cFNbKmAjkI=; b=2f969ornikTFlR/GOYoynm00UOV7V7OqAjU3G4XFN48VyPlj1VGn4qLWHjXSBtG73ArrEu 6uRCOVIcZpzFeJXvqmXuO8nE3P7bF60BCP9zHC2WDuYev0bbTqzpcZiokuuTRCqWTK9RP0 eekkCeOUaMDkoLqeLOINfPeFahZD2dQ= Received: from [192.168.1.160] (cpe-24-24-163-126.socal.res.rr.com [24.24.163.126]) by mail.nomadlogic.org (OpenSMTPD) with ESMTPSA id 4bdf87fd (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Tue, 6 Jul 2021 23:01:27 +0000 (UTC) Subject: Re: ZFS + mysql appears to be killing my SSD's To: Alan Somers , Pete French Cc: Stefan Esser , FreeBSD Stable Mailing List References: <89c37c3e-22e8-006e-5826-33bd7db7739e@ingresso.co.uk> <2fd9b7e4-dc75-fedc-28d7-b98191167e6b@freebsd.org> <9c71d627-55b8-2464-6cc9-489e4ce98049@ingresso.co.uk> Message-ID: <2e6dbe13-e08f-1dab-1f5b-76a90c3a2ea7@nomadlogic.org> Date: Tue, 6 Jul 2021 16:01:25 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 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 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Rspamd-Queue-Id: 4GKJ2m3sLXz3jfP X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=nomadlogic.org header.s=04242021 header.b=2f969orn; dmarc=pass (policy=quarantine) header.from=nomadlogic.org; spf=pass (mx1.freebsd.org: domain of pete@nomadlogic.org designates 66.165.241.226 as permitted sender) smtp.mailfrom=pete@nomadlogic.org X-Spamd-Result: default: False [-3.57 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[nomadlogic.org:s=04242021]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-0.57)[-0.575]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; SPAMHAUS_ZRD(0.00)[66.165.241.226:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[nomadlogic.org:+]; DMARC_POLICY_ALLOW(-0.50)[nomadlogic.org,quarantine]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[66.165.241.226:from]; ASN(0.00)[asn:29802, ipnet:66.165.240.0/22, country:US]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-stable]; RCVD_COUNT_TWO(0.00)[2] Reply-To: pete@nomadlogic.org From: Pete Wright via freebsd-stable X-Original-From: Pete Wright X-ThisMailContainsUnwantedMimeParts: N On 7/5/21 7:51 AM, Alan Somers wrote: > > If you're using 4K sectors anyway, then GELI does not create any extra > write amplification. But if you're extra paranoid and you use the "-T" > option to "geli attach", then GELI will block TRIM commands. That could > hurt SSD lifetime. But I don't think "-T" is the default. You are using > 4K sectors, right? ZFS's ashift is set to 12? > -Alan > i also wonder if this could be a TRIM related issue.  according to zpoolprops(8) TRIM is not enabled by default on pools - but it also has this note (see autotrim): "Be aware that automatic trimming of recently freed data blocks can put significant stress on the underlying storage devices. This will vary depending of how well the specific device handles these commands.  For lower end devices it is often possible to achieve most of the benefits of automatic trimming by running an on-demand (manual) TRIM periodically using the zpool trim command." I wonder if adjusting the autotrim feature will address these issues - i manually enable autotrim for my pools and have seen no bad effects under quite of bit of bursty i/o.  if it is enabled i wonder if the ssd you are using doesn't play nice with autotrim and should stay disabled? -p -- Pete Wright pete@nomadlogic.org @nomadlogicLA From nobody Wed Jul 7 10:04:46 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 D66041224387 for ; Wed, 7 Jul 2021 10:04:57 +0000 (UTC) (envelope-from petefrench@ingresso.co.uk) Received: from constantine.ingresso.co.uk (constantine.ingresso.co.uk [IPv6:2001:470:6a18:411::3]) (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 4GKZm95lmrz4VTf; Wed, 7 Jul 2021 10:04:57 +0000 (UTC) (envelope-from petefrench@ingresso.co.uk) Received: from [2001:470:6cc4:1:cd6:5836:ddba:7b54] (helo=balta.drayhouse.twisted.org.uk) by constantine.ingresso.co.uk with esmtpsa (TLS1.3) tls TLS_AES_128_GCM_SHA256 (Exim 4.94.2 (FreeBSD)) (envelope-from ) id 1m14QD-0002dw-NP; Wed, 07 Jul 2021 10:04:49 +0000 Subject: Re: ZFS + mysql appears to be killing my SSD's To: Pete Wright , Alan Somers Cc: Stefan Esser , FreeBSD Stable Mailing List References: <89c37c3e-22e8-006e-5826-33bd7db7739e@ingresso.co.uk> <2fd9b7e4-dc75-fedc-28d7-b98191167e6b@freebsd.org> <9c71d627-55b8-2464-6cc9-489e4ce98049@ingresso.co.uk> <2e6dbe13-e08f-1dab-1f5b-76a90c3a2ea7@nomadlogic.org> From: Pete French Message-ID: Date: Wed, 7 Jul 2021 11:04:46 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 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 In-Reply-To: <2e6dbe13-e08f-1dab-1f5b-76a90c3a2ea7@nomadlogic.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4GKZm95lmrz4VTf X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: N On 07/07/2021 00:01, Pete Wright wrote: > i also wonder if this could be a TRIM related issue.  according to > zpoolprops(8) TRIM is not enabled by default on pools - but it also has > this note (see autotrim): > > "Be aware that automatic trimming of recently freed data blocks > can put significant stress on the underlying storage devices. > This will vary depending of how well the specific device handles > these commands.  For lower end devices it is often possible to > achieve most of the benefits of automatic trimming by running an > on-demand (manual) TRIM periodically using the zpool trim > command." > > > I wonder if adjusting the autotrim feature will address these issues - i > manually enable autotrim for my pools and have seen no bad effects under > quite of bit of bursty i/o.  if it is enabled i wonder if the ssd you > are using doesn't play nice with autotrim and should stay disabled? I was thinking this too - the autotrim stuff came in with OpenZFS, but I had trim enabled previously (I believe we had our own implementation on FreeBSD ZFS, is that right?). But I am wondering if a schduled trim might be a better option. Though the question arises as to 'how often' in that case. -pete. From nobody Wed Jul 7 12:17:39 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 D434F8D6FF3; Wed, 7 Jul 2021 12:17:48 +0000 (UTC) (envelope-from trashcan@ellael.org) Received: from mx1.enfer-du-nord.net (mx1.enfer-du-nord.net [91.121.41.56]) (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 4GKdjR5tgBz4pWw; Wed, 7 Jul 2021 12:17:47 +0000 (UTC) (envelope-from trashcan@ellael.org) Received: from smtpclient.apple (p200300Fb4F0558010938f8309A8230D1.dip0.t-ipconnect.de [IPv6:2003:fb:4f05:5801:938:f830:9a82:30d1]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.enfer-du-nord.net (Postfix) with ESMTPSA id 4GKdjJ1hrGzh1X; Wed, 7 Jul 2021 14:17:40 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ellael.org; s=dkim; t=1625660260; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=tAISFw/mN9MIcEZNVA3CPuTvgXYg5P6g8Hic53xw09o=; b=sNGkRoQKFanDeX0ubuJr7N6PHHVZ/lIGGBmXSCVzhKozbc6e8Z3Cd8BGE/898RcwNoG1cu saiuQO1zCiZuwvzCJg/zqDmzsneAXkXrApN/SzQBNV0vwc3LHtGEOsetV5oBnwU7CG/aFb Iwpa618NTc7R6G2nP2A2cB6H04Yni6RcdT/yk09C7O+9/7aeDbJnt4/OA4XqxKEEgxQD9m j96s4xugMlN7fh/WFwCBEjIpEKDNvK1BkUFcpcxv4/43s5wsMBnLKuGdq1uclkMVTKmoyf WqtEaTrC/RfVXfbn7uNMQWk0CpDwynEF9LlhfMhQ9RkvGOR1F45hcCdudOzF+g== Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Subject: security/rkhunter without hashes after recent STABLE-13 update Message-Id: <416D3033-138D-4BBB-84FA-FAEA2944C837@ellael.org> Date: Wed, 7 Jul 2021 14:17:39 +0200 Cc: lukasz@wasikowski.net To: FreeBSD-STABLE Mailing List , FreeBSD ports X-Mailer: Apple Mail (2.3654.100.0.2.22) X-Rspamd-Queue-Id: 4GKdjR5tgBz4pWw X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=ellael.org header.s=dkim header.b=sNGkRoQK; dmarc=pass (policy=quarantine) header.from=ellael.org; spf=pass (mx1.freebsd.org: domain of trashcan@ellael.org designates 91.121.41.56 as permitted sender) smtp.mailfrom=trashcan@ellael.org X-Spamd-Result: default: False [-3.50 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[ellael.org:s=dkim]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:91.121.41.56]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_DN_SOME(0.00)[]; SPAMHAUS_ZRD(0.00)[91.121.41.56:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[ellael.org:+]; DMARC_POLICY_ALLOW(-0.50)[ellael.org,quarantine]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.996]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[91.121.41.56:from]; ASN(0.00)[asn:16276, ipnet:91.121.0.0/16, country:FR]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-ports,freebsd-stable]; RCVD_COUNT_TWO(0.00)[2] Reply-To: trashcan@ellael.org From: Michael Grimm via freebsd-stable X-Original-From: Michael Grimm X-ThisMailContainsUnwantedMimeParts: N Hi, I noticed that after my last upgrade to stable/13-n246157 (from = stable/13-n246147) that /usr/local/var/lib/rkhunter/db/rkhunter.dat = started lacking hashes. Regarding rkhunter.conf the default setting is: HASH_CMD=3DSHA256 and: If just the command name is given, and it is one of MD5,=20 SHA1, SHA224, SHA256, SHA384 or SHA512, then rkhunter will first = look for the=20 relevant command, such as 'sha256sum', and then for 'sha256'. If I do modify the setting to ... HASH_CMD=3D/sbin/sha256 =E2=80=A6 rkhunter.dat shows hashes again. Ok, that can be fixed.=20 But I wonder if my findings have something to do with security/rkhunter = at all, because that port didn't change recently.=20 Can someone point me into the right direction, how to find out if the = output of /sbin/sha256sum changes between stable/13-n246147 and = stable/13-n246157? Regards, Michael= From nobody Wed Jul 7 14:51:36 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 EC8218D355F for ; Wed, 7 Jul 2021 14:51:48 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (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 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GKj784P88z3Nc2 for ; Wed, 7 Jul 2021 14:51:48 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x731.google.com with SMTP id b18so2189008qkc.5 for ; Wed, 07 Jul 2021 07:51:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2I/zZGhzVQI/g/mxHkopl4kL8hVOSb7DQw3aVU5sLpU=; b=vU6kFo9gz04ONdx106Ea1OZeCTkjtKANtRvrvZ+L5m57o97ZypvRi76ZkkmAzDNk43 OA50tYzqNd4UVa6PaM196YyP6TgHS11ZxBUYcpGXQhVgK/dEPufMz8pmyRhJvIuVfCLJ ZwFep7wpa60LBWrhc7NiclLbFjHBujWfmXlNU2RJCrvklKwfNCLU8GpILpUoxlbU46Sv D2JOmyfdlddp3pIIa8hxJfQ/SCazHZCtGhjmsfNVTNksNUzE78EAHngnkS6tn2k+CsTy dKwwaQIo6CcStQMORyiI2C36/8ca5tcZfUHf0Er0sWroHqpVI8CLVLR0YLGHWY05+mTH mAcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2I/zZGhzVQI/g/mxHkopl4kL8hVOSb7DQw3aVU5sLpU=; b=Y9bAjU7JBn2Nbs+y6QFYN4RXJrgYHIMMCrvT22ImkqCikdDyWNqCoBxGbanoOT4j7b G1fLh3izB2CVSUwgZ3JhZcKlmzZa6SOxxv4oz4ohxzwbvr6U7G5eR9G4fG3XL/LTU68F qWVh5pLp45wsKoI4FSG9pQZk4+Z+k50Ia6/RZAqslvmgEwlEGqrHRG2FZsVeOdnb/LXC h+rHxwrk7seEvFiNmz5ZjNdOIC4xaryKZjJJA99N6UoQt2N77rFHdX8mdNbTfsx6bI43 gfKNsyJ4/n0Bwg3WKwVrvY6WzJnfN+EdWhxtVwRBtMlIMZBPt3X5DY7rxjIANGP3nJ74 teSg== X-Gm-Message-State: AOAM530/30k82ni44hDnl6Q2n782J6gWkjlVQgBwXrVWbKSiK2RaGcVO 6l4eHISvgpv3zl351POiRc82B07tk+nsuT+NVtIpJQ== X-Google-Smtp-Source: ABdhPJwGj4rMSPFPF1OiIxMrRbWZnY4SQWLUKjW8kqQ0AosBizBnEjp3t8n0eMKkbvm7T+t5SBIpatHGHymAkQVVg28= X-Received: by 2002:a05:620a:e09:: with SMTP id y9mr25676826qkm.359.1625669507451; Wed, 07 Jul 2021 07:51:47 -0700 (PDT) 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 References: <416D3033-138D-4BBB-84FA-FAEA2944C837@ellael.org> In-Reply-To: <416D3033-138D-4BBB-84FA-FAEA2944C837@ellael.org> From: Warner Losh Date: Wed, 7 Jul 2021 08:51:36 -0600 Message-ID: Subject: Re: security/rkhunter without hashes after recent STABLE-13 update To: Michael Grimm Cc: FreeBSD-STABLE Mailing List , FreeBSD ports , lukasz@wasikowski.net, Stefan Esser Content-Type: multipart/alternative; boundary="000000000000839c7905c689ad82" X-Rspamd-Queue-Id: 4GKj784P88z3Nc2 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y --000000000000839c7905c689ad82 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jul 7, 2021 at 6:19 AM Michael Grimm via freebsd-stable < freebsd-stable@freebsd.org> wrote: > Hi, > > I noticed that after my last upgrade to stable/13-n246157 (from > stable/13-n246147) that /usr/local/var/lib/rkhunter/db/rkhunter.dat start= ed > lacking hashes. > > Regarding rkhunter.conf the default setting is: > > HASH_CMD=3DSHA256 > > and: > > If just the command name is given, and it is one of MD5, > SHA1, SHA224, SHA256, SHA384 or SHA512, then rkhunter will first > look for the > relevant command, such as 'sha256sum', and then for 'sha256'. > > If I do modify the setting to ... > > HASH_CMD=3D/sbin/sha256 > > =E2=80=A6 rkhunter.dat shows hashes again. > > > Ok, that can be fixed. > > But I wonder if my findings have something to do with security/rkhunter a= t > all, because that port didn't change recently. > > Can someone point me into the right direction, how to find out if the > output of /sbin/sha256sum changes between stable/13-n246147 and > stable/13-n246157? > This is likely an incompletely merged set of changes to md5, et al. I recently added the 'sum' variations, but did so from an incomplete description so I got the output format wrong in a couple of cases. se@ went in and fixed that, and added a lot of compat tests to make sure they weren't further regressions. b33d1898c1b0 is the latest fix, from Jun 29th in -current and merged to stable/13 Jul 6th. It's at n246188 so a little too late unless you have a slight kernel mismatch with your userland/jail. I didn' tsee any changes between n246147 or n146157 that would do this, though. What's the hash that you have at n246157? I think it should be fd5b08977630. So the change is expected, but if the change to all the *sum programs is incompatible still, I know I'd like to know (as I'm sure se@ would as well). All the *sum programs are very new and designed to be 100% compatible with the linux versions and if they aren't that needs to be fixed. Warner --000000000000839c7905c689ad82-- From nobody Wed Jul 7 15:25:50 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 8B31411D8577; Wed, 7 Jul 2021 15:26:07 +0000 (UTC) (envelope-from trashcan@ellael.org) Received: from mx2.enfer-du-nord.net (mx2.enfer-du-nord.net [135.125.211.209]) (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 4GKjtl2nF4z3k25; Wed, 7 Jul 2021 15:26:07 +0000 (UTC) (envelope-from trashcan@ellael.org) Received: from smtpclient.apple (p200300Fb4F0558010938f8309A8230D1.dip0.t-ipconnect.de [IPv6:2003:fb:4f05:5801:938:f830:9a82:30d1]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx2.enfer-du-nord.net (Postfix) with ESMTPSA id 4GKjtZ53ZvzVC; Wed, 7 Jul 2021 17:25:58 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ellael.org; s=dkim; t=1625671559; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=s9QNjfIUNuoTMxDyJmkrr41Z4ACt60UWHW+Q1kuEKbE=; b=vC3JuTr806vatpRtdQ1LNvdNi0LVf9ORBblDZVXhMzeN6XvbRbcdo1sSl7xGfjgeu6RuMo Q6l6coQSexd/pkbaQ7FPz+/ez1i/3/zCJjYMqksQ318GVeO+dkNnhlNzurGKRXqbNJQjfa b3UNjrgwZ+CFNxjLGOIzvZ2M9/sLxuJ7u4WROyUZA5mBHGWMcwnihEyUhHaSdaWfD1P8SQ GQ2V2yfmqcK491V0IwQtkEv7+XK2W1+g+xHGU71buMzcXAEh3R10TKuMZG4oiXSqpDf9vv m4Qth6n5mdiyRjMy9pgWHdtl7yjaGfXFPBSU6FFJREHf2ENSA4linCA4cHa9NA== Content-Type: text/plain; charset=utf-8 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 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Subject: Re: security/rkhunter without hashes after recent STABLE-13 update In-Reply-To: Date: Wed, 7 Jul 2021 17:25:50 +0200 Cc: FreeBSD-STABLE Mailing List , FreeBSD ports , lukasz@wasikowski.net, Stefan Esser Content-Transfer-Encoding: quoted-printable Message-Id: References: <416D3033-138D-4BBB-84FA-FAEA2944C837@ellael.org> To: Warner Losh X-Mailer: Apple Mail (2.3654.100.0.2.22) X-Rspamd-Queue-Id: 4GKjtl2nF4z3k25 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: trashcan@ellael.org From: Michael Grimm via freebsd-stable X-Original-From: Michael Grimm X-ThisMailContainsUnwantedMimeParts: N Warner Losh wrote: >=20 > On Wed, Jul 7, 2021 at 6:19 AM Michael Grimm via freebsd-stable = wrote: >> Can someone point me into the right direction, how to find out if the >> output of /sbin/sha256sum changes between stable/13-n246147 and >> stable/13-n246157? >=20 > This is likely an incompletely merged set of changes to md5, et al. I > recently added the 'sum' variations, but > did so from an incomplete description so I got the output format wrong = in a > couple of cases. se@ went in and > fixed that, and added a lot of compat tests to make sure they weren't > further regressions. >=20 > b33d1898c1b0 is the latest fix, from Jun 29th in -current and merged = to > stable/13 Jul 6th. It's at n246188 so a little too late unless you = have a > slight kernel mismatch with your userland/jail. I didn' tsee any = changes > between n246147 or n146157 that would do this, though. What's the hash = that > you have at n246157? I think it should be fd5b08977630. No, it's stable/13-n246157-fd5b0897763 I will give a n246188+ user land a try, and ... > So the change is expected, but if the change to all the *sum programs = is > incompatible still, I know I'd like to know (as I'm sure se@ would as > well). All the *sum programs are very new and designed to be 100% > compatible with the linux versions and if they aren't that needs to be > fixed. =E2=80=A6 I will report back. Regards, Michael =20= From nobody Wed Jul 7 15:52:21 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 4B4F011DC872 for ; Wed, 7 Jul 2021 15:52:34 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qv1-xf36.google.com (mail-qv1-xf36.google.com [IPv6:2607:f8b0:4864:20::f36]) (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 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GKkTG1K55z3nVw for ; Wed, 7 Jul 2021 15:52:33 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qv1-xf36.google.com with SMTP id ck17so762231qvb.9 for ; Wed, 07 Jul 2021 08:52:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KLfCcplEO69tl0N/JR3O0CS2cSSJ7z270vU3GH5LA9o=; b=Q9UuUUaucgtM1lzzBGIbXKhvRyUXNFruCGYlaOvhq83bwzFDW68ctBkThj+yXPQDAL Ja4Eto4j0Fr7uJDwZvdmGp5bivfFgoaogK+Pnshjwl9a22qqPh10mb6VcqjxpTkAo3j+ ZAuuiYvMIA3n2q0vC+QsmDnfLTyz2AXc1Zn/WV+WuiZncIs78W22xtBxiY9eKR1eCuXX p1y+IBdj/zk5hoG+Qg7qfp5NaVxRIflHiOVSOu6Oohu0FlSmr4rKCOjzY2IhwgH4y4Xr 6djpWq2s68kzMFEMdfJXY8jrxCg+jpSNAyZeSXrUpkZLd3nuYL7cPTtfyaX33XDc2xgV q2DA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KLfCcplEO69tl0N/JR3O0CS2cSSJ7z270vU3GH5LA9o=; b=e8eNih2VfTYR0+6WVhm64cGvxqBe7d7M2Z+4tTZq1zlQ30izdMomZ8IA6Uy353XxPh gV+SbUC9GpszOE/WfEQTNBpYHMm0QOBRapxYN+Dt4fWV0D1fZn1Ubc0lEav7qf1CnvLU VlGTjRDOuRRqVQmTQiy1FabTP6IdCrH7qeJJ3BaTcgBcAWe6i9A5Wx9zxNV9qyuJvoJc BA5GSPQz6P/Yo1afFciJQrJbl/IZ/kh9U5CTCa/2kanKH78mDTR9Nk+WJ/rJ5bdZIKye Gh5/dybVNIx9JBMRUdVzpxlFdmUf3PwXF2SfzgWTk6F0sXEuccRkhImP4PqC3mPw2zWh H3Ew== X-Gm-Message-State: AOAM5331knJYB/x59epHT6MXB6dJd2sn6aHOJPPQ9OPULi7b2XxSuGg4 7rnMoUd4TlyNdK2G24PUGTdkzXDEFQ0NsIAJ7G9AvQ== X-Google-Smtp-Source: ABdhPJzmAOil7AyrF52qoj16MoVeXkqUaZpsFm339vHnm/xyqqg9wR/W1IBYitgecISNtYRdlG3mCn4hsl5L8RLaGWo= X-Received: by 2002:a05:6214:b31:: with SMTP id w17mr24479571qvj.24.1625673153222; Wed, 07 Jul 2021 08:52:33 -0700 (PDT) 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 References: <416D3033-138D-4BBB-84FA-FAEA2944C837@ellael.org> In-Reply-To: From: Warner Losh Date: Wed, 7 Jul 2021 09:52:21 -0600 Message-ID: Subject: Re: security/rkhunter without hashes after recent STABLE-13 update To: Michael Grimm Cc: FreeBSD-STABLE Mailing List , FreeBSD ports , lukasz@wasikowski.net, Stefan Esser Content-Type: multipart/alternative; boundary="000000000000d1aaa605c68a86fb" X-Rspamd-Queue-Id: 4GKkTG1K55z3nVw X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y --000000000000d1aaa605c68a86fb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jul 7, 2021 at 9:26 AM Michael Grimm wrote: > Warner Losh wrote: > > > > On Wed, Jul 7, 2021 at 6:19 AM Michael Grimm via freebsd-stable < > freebsd-stable@freebsd.org> wrote: > > >> Can someone point me into the right direction, how to find out if the > >> output of /sbin/sha256sum changes between stable/13-n246147 and > >> stable/13-n246157? > > > > This is likely an incompletely merged set of changes to md5, et al. I > > recently added the 'sum' variations, but > > did so from an incomplete description so I got the output format wrong > in a > > couple of cases. se@ went in and > > fixed that, and added a lot of compat tests to make sure they weren't > > further regressions. > > > > b33d1898c1b0 is the latest fix, from Jun 29th in -current and merged to > > stable/13 Jul 6th. It's at n246188 so a little too late unless you have= a > > slight kernel mismatch with your userland/jail. I didn' tsee any change= s > > between n246147 or n146157 that would do this, though. What's the hash > that > > you have at n246157? I think it should be fd5b08977630. > > No, it's stable/13-n246157-fd5b0897763 > > I will give a n246188+ user land a try, and ... > Great. Please do let me know... I started this for compatibility so I didn't have to keep hacking simple scripts for FreeBSD and if something is screwed up that means it's falling short of the goal... > > So the change is expected, but if the change to all the *sum programs i= s > > incompatible still, I know I'd like to know (as I'm sure se@ would as > > well). All the *sum programs are very new and designed to be 100% > > compatible with the linux versions and if they aren't that needs to be > > fixed. > > =E2=80=A6 I will report back. Excellent! Sorry for any hassle this work is causing. Warner --000000000000d1aaa605c68a86fb-- From nobody Wed Jul 7 17:05:12 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 E3CB811E75D2 for ; Wed, 7 Jul 2021 17:05:23 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qv1-xf33.google.com (mail-qv1-xf33.google.com [IPv6:2607:f8b0:4864:20::f33]) (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 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GKm5H5trFz4S32 for ; Wed, 7 Jul 2021 17:05:23 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qv1-xf33.google.com with SMTP id d2so1392078qvh.2 for ; Wed, 07 Jul 2021 10:05:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=q0+fWFJ3gabFhV3v+s2DuIw+4fwOQF+xOJkcOE+Rt+I=; b=s9y5x8rYN0ytvARe63Ya8aTb7Mh8L/DT6WrHsUEPJzpRCvqs5njwcB0O07M/p9fseI DcfANSwEd74+VT1ony95P1IEIkiuYfX7Q929I56HuOPlGiMkjfO9f9JjueVwroLYEsj/ PiaLDcQtWWbpnsW3q/yXDJVXb70MxJniDrvFs8V+GlTWjoql8CIzBUrPkAY3ter+98m2 yHzgYNOj+50Jv+N6q9xzrZSaR3baVHX51jsj4eOVe0ZqbDBgpXGDIsV+HMRpkKz/IhgJ cQONiDpMEt6NVjxT4KRPvNhniOo018vbJe6+IB7KqWL+xdIB74iuNFpFqq8hcUUT36WN vyIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=q0+fWFJ3gabFhV3v+s2DuIw+4fwOQF+xOJkcOE+Rt+I=; b=TtmFRkAQTJCAvwGkh6NhhRIoLND11pDXlv5mxIIpdAesZMKkLZFKolo3B1dBiGcuLx BXq2MPZD7laHBAfbFvBgpRJMEUkvcgdUQZV77ZqLH6B3MkscfJ2/+dr0Ke7kNHWoLKQc 4RQhuw2e+24AroKftbRWxKwZB+GGCDeq9r7usbG5HlB6X1iRK+CP7VYskKmN2Nug2nOQ LYXe8u0h9NqI6DMajMs+b5HigNCagcZhgk117BF92ShJgJ92Pw5Buud23E6Hksg+i3ms 3MiP0Kvz0v7WKeIIRrwkYulcQ3QyeGt490YmU6gwxYH2TwQL5wVNlAjWrAJqFF7EKj/K ++YQ== X-Gm-Message-State: AOAM5336wUe8W2kGdyUv1hfoXIPMKXbDGc7CGuDC9e8J93J/mGWbP5EC DrDBm/t83f0TIn9VrPDEENIp3fuERw1gSBihQbMO7w== X-Google-Smtp-Source: ABdhPJwR473gU8QfebxOgHcom/uQJzuJ5lrD70FOl1nj+Gz3EN7F3wfZfuRdU2nkIWTXI+lTJFaM/9xyGLMqDcTA2YE= X-Received: by 2002:a0c:d7c4:: with SMTP id g4mr24412867qvj.23.1625677522892; Wed, 07 Jul 2021 10:05:22 -0700 (PDT) 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 References: <89c37c3e-22e8-006e-5826-33bd7db7739e@ingresso.co.uk> <2fd9b7e4-dc75-fedc-28d7-b98191167e6b@freebsd.org> <9c71d627-55b8-2464-6cc9-489e4ce98049@ingresso.co.uk> <2e6dbe13-e08f-1dab-1f5b-76a90c3a2ea7@nomadlogic.org> In-Reply-To: From: Warner Losh Date: Wed, 7 Jul 2021 11:05:12 -0600 Message-ID: Subject: Re: ZFS + mysql appears to be killing my SSD's To: Pete French Cc: Pete Wright , Alan Somers , Stefan Esser , FreeBSD Stable Mailing List Content-Type: multipart/alternative; boundary="000000000000458fc005c68b8bc9" X-Rspamd-Queue-Id: 4GKm5H5trFz4S32 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y --000000000000458fc005c68b8bc9 Content-Type: text/plain; charset="UTF-8" On Wed, Jul 7, 2021 at 4:06 AM Pete French wrote: > > > On 07/07/2021 00:01, Pete Wright wrote: > > > i also wonder if this could be a TRIM related issue. according to > > zpoolprops(8) TRIM is not enabled by default on pools - but it also has > > this note (see autotrim): > > > > "Be aware that automatic trimming of recently freed data blocks > > can put significant stress on the underlying storage devices. > > This will vary depending of how well the specific device handles > > these commands. For lower end devices it is often possible to > > achieve most of the benefits of automatic trimming by running an > > on-demand (manual) TRIM periodically using the zpool trim > > command." > > > > > > I wonder if adjusting the autotrim feature will address these issues - i > > manually enable autotrim for my pools and have seen no bad effects under > > quite of bit of bursty i/o. if it is enabled i wonder if the ssd you > > are using doesn't play nice with autotrim and should stay disabled? > > I was thinking this too - the autotrim stuff came in with OpenZFS, but I > had trim enabled previously (I believe we had our own implementation on > FreeBSD ZFS, is that right?). But I am wondering if a schduled trim > might be a better option. Though the question arises as to 'how often' > in that case. > Two observations about this whole thread. First: the cheapest SSDs have a much lower DWPD (drive writes per day) rating now than they used to have. A few years ago, 3DWPD was normal, now it's closer to 0.3DWPD. If your drives are wearing out faster now than before, this may well be why. If you have a large write workload, you'll almost certainly need to buy more expensive drives with higher DWPD ratings. In general, the cost difference between the drives is small enough that over-provisioning this by a factor of about 10-20 (meaning if you think you only need 0.3DWPD, buy a 3DWPD drive), especially for smaller deployments where your time to replace the bad drives will easily exceed the delta in cost up front. Second, TRIM should help reduce write amplification that happens inside the drive. Ideally, it should be done inline. However, that's not always performant due to the quality of TRIM implementations on some drives. That's why the automated periodic TRIM features were added. TRIMs are most effective when you have lots of data that's written and shortly after becomes idle for a long time. If it's written and then is rewritten quickly after the blocks are released, then TRIMs have much less effect on the write amp than if there's a period of time that elapses. Which brings us to how often. That's tricky. A lot of that depends on the performance impact the TRIMs have on the on-going operations and expected lifetime of the recently written "cold" data (data that will stick around for a while). Daily is likely a good place to start, ideally at an off time. I don't really know your workload that well, so I can't say for sure, but that's a good place to start. TRIMs can only help the internal writeamp of the drive's FTL, but won't help the raw write rate. You'll need to change your application to reduce writes if you must write in excess of your drive's DWPD. FreeBSD's old ZFS had its own implementation, but that was never ported to OpenZFS. It was replaced by a better implementation with which I'm not too familiar. Warner --000000000000458fc005c68b8bc9-- From nobody Wed Jul 7 18:47:36 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 3FC231226266; Wed, 7 Jul 2021 18:47:46 +0000 (UTC) (envelope-from trashcan@ellael.org) Received: from mx2.enfer-du-nord.net (mx2.enfer-du-nord.net [IPv6:2001:41d0:701:1000::1685]) (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 4GKpMQ0XpRz4jH0; Wed, 7 Jul 2021 18:47:45 +0000 (UTC) (envelope-from trashcan@ellael.org) Received: from smtpclient.apple (p200300fb4f0558010938F8309a8230D1.dip0.t-ipconnect.de [IPv6:2003:fb:4f05:5801:938:f830:9a82:30d1]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx2.enfer-du-nord.net (Postfix) with ESMTPSA id 4GKpMF4DCRzfR; Wed, 7 Jul 2021 20:47:37 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ellael.org; s=dkim; t=1625683657; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=zgKVcjthq8dFr1kuYQ22kGOTlEpCJZeYixvGiyzH6SY=; b=YYejBfHy8xLk49coqWSYJ5599YLAMkKeB4K/B1Wt8uPR5Bkcz747BqxNRLpvwqEMNNb889 uZfL/hWMp9q0KAVpmfF1099w73+kUnE4MGVCAyQfsJ+qIT5ppI+HBNI6z8EMBf6fOFqGTe yHCAPVOCLjRa4vDUZAt/JEdPZofGdyZQFZzMZxseZBNL7dBAeE2MHOi/iH42OEImsd9RKd NiUBXbUZFrqqi98/2EpJJ1kkzOUBWnDhjf+oba2sTG7uTnUxyPXbAbqj96fjCb1vrPXWpG jEGGogAW4aGfPeNqPWwBmHbgT4PYsNrvZq6YorvHaAz8SYmi08IHSDOzhIrJ0A== Content-Type: text/plain; charset=utf-8 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 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Subject: Re: security/rkhunter without hashes after recent STABLE-13 update In-Reply-To: Date: Wed, 7 Jul 2021 20:47:36 +0200 Cc: FreeBSD-STABLE Mailing List , FreeBSD ports , lukasz@wasikowski.net, Stefan Esser Content-Transfer-Encoding: quoted-printable Message-Id: <08637D0D-9D65-4F53-9A64-F4742BA8E415@ellael.org> References: <416D3033-138D-4BBB-84FA-FAEA2944C837@ellael.org> To: Warner Losh X-Mailer: Apple Mail (2.3654.100.0.2.22) X-Rspamd-Queue-Id: 4GKpMQ0XpRz4jH0 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: trashcan@ellael.org From: Michael Grimm via freebsd-stable X-Original-From: Michael Grimm X-ThisMailContainsUnwantedMimeParts: N Warner Losh wrote: > On Wed, Jul 7, 2021 at 9:26 AM Michael Grimm = wrote: >> Warner Losh wrote: >>> What's the hash that you have at n246157? I think it should be = fd5b08977630. >>=20 >> No, it's stable/13-n246157-fd5b0897763 >>=20 >> I will give a n246188+ user land a try, and ... >=20 > Great. Please do let me know... I started this for compatibility so I > didn't have > to keep hacking simple scripts for FreeBSD and if something is screwed = up > that means it's falling short of the goal... >=20 >>> So the change is expected, but if the change to all the *sum = programs is >>> incompatible still, I know I'd like to know (as I'm sure se@ would = as >>> well). All the *sum programs are very new and designed to be 100% >>> compatible with the linux versions and if they aren't that needs to = be >>> fixed. >>=20 >> =E2=80=A6 I will report back. >=20 > Excellent! I am running stable/13-n246205-9e06b34bb5d, now.=20 But I do have to report that rkhunter is still lacking to calculate = hashes when using sha256sum instead of sha256. In a previous mail you wrote: "I recently added the 'sum' variations".=20= Does that mean that sha256sum (et al.) didn't exist before? That could = explain why rkhunter didn't fail before. Example output: KBN> sha256 crontab.mike=20 SHA256 (test.dat) =3D = 829f9293639f1a590757bf3eaa369c102b071ef450d3f196e29d5c810f23a2c9 KBN> sha256sum test.dat 829f9293639f1a590757bf3eaa369c102b071ef450d3f196e29d5c810f23a2c9 = test.dat If I am not mistaken does rkhunter cut that output string into relevant = junks. In both cases the hash is at different positions, though ... > Sorry for any hassle this work is causing. No big deal for rkhunter, a workaround exists ;-) Regards, Michael From nobody Wed Jul 7 19:49:36 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 5C2728D656C for ; Wed, 7 Jul 2021 19:49:48 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qv1-xf2b.google.com (mail-qv1-xf2b.google.com [IPv6:2607:f8b0:4864:20::f2b]) (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 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GKql01nD6z4qxt for ; Wed, 7 Jul 2021 19:49:48 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qv1-xf2b.google.com with SMTP id c5so1632401qvu.11 for ; Wed, 07 Jul 2021 12:49:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8xXRzOnXvWogURprUopV0NDPpYTb05HgarjB9AxDixc=; b=uMA4DP2xYli3X43K0Ht1OsfFEM7Hi/0DJvgzSKlPVJhI5f+7sazazDHRI1TcA83s7t EEZdXCT+LEIvOXzfE3U+hAkjhWWOMMDikcnjvj9DrFXQYv/tPLav+tjmdGNKwpFPOfJj H2qols3CrjOxHVsNIOm6suwyhPp0xcdheF926/QLsQriH08RTHkznVW9csbU9lRKJDmi 3ulPIagkYvzW+D1l/XsDC/Sw4A/EBlOJVKSSdaX11CiQy11OA0IJtzeqTUQZ9nfysviZ 9MVREabJfzZZYs5/snyNInpTRyOlphurTBPKAtLfJTHfEdQ2fBQCAapfdEF13vyXBj4N 6yyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8xXRzOnXvWogURprUopV0NDPpYTb05HgarjB9AxDixc=; b=G/bqzCRaBPZtrww+D5JJa8umq+8ppMH0wNfssR+0DhKRIZblIEJNeRDoWIz7P8fOW2 ncn0s9oYIAWXpO4sD2HWavGac5R5CEgh6DUfHQyZIu4GUsw4hfmrlkfwxkbc8XrzJPxz RWiiq4ieIVtY8rgWx7BNpP+KVhZ05D2GSah0VXB/+UXgEcnFH8rOi1QaHlnIyzvQQix9 OguBj9Xngo1qQu1oSdqWuovLCNkOLLKlGUjzPx+RCRoFyeb79nUCQaTz1o166s7J1/Xq dVGEpcznGxOId+LEVOynCjt/jVnFzGwrMqz/SwysXX4lokvAFZ7z147ouCZcVIWM+rVr qtDA== X-Gm-Message-State: AOAM530x/TZicFTEN7DlCzkZKBTwOoMpmJNWirUb5vZgM18vnOU0S23k OMBo/UeNXHdCav4ZN/HQmcieuA8AvhqDUaLkVKTNug== X-Google-Smtp-Source: ABdhPJxlbeRBgjjt/tWDEWhLfeVHA8huK3ALjafZGsXgxr2T5rRZvmlh3SJtU0ADgecjPLktt1kJ56OLFBwR2DUR+3k= X-Received: by 2002:a05:6214:1a0f:: with SMTP id fh15mr25603073qvb.29.1625687387094; Wed, 07 Jul 2021 12:49:47 -0700 (PDT) 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 References: <416D3033-138D-4BBB-84FA-FAEA2944C837@ellael.org> <08637D0D-9D65-4F53-9A64-F4742BA8E415@ellael.org> In-Reply-To: <08637D0D-9D65-4F53-9A64-F4742BA8E415@ellael.org> From: Warner Losh Date: Wed, 7 Jul 2021 13:49:36 -0600 Message-ID: Subject: Re: security/rkhunter without hashes after recent STABLE-13 update To: Michael Grimm Cc: FreeBSD-STABLE Mailing List , FreeBSD ports , lukasz@wasikowski.net, Stefan Esser Content-Type: multipart/mixed; boundary="00000000000039818a05c68dd76d" X-Rspamd-Queue-Id: 4GKql01nD6z4qxt X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y --00000000000039818a05c68dd76d Content-Type: multipart/alternative; boundary="00000000000039818805c68dd76b" --00000000000039818805c68dd76b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jul 7, 2021 at 12:47 PM Michael Grimm wrote: > Warner Losh wrote: > > On Wed, Jul 7, 2021 at 9:26 AM Michael Grimm > wrote: > >> Warner Losh wrote: > > >>> What's the hash that you have at n246157? I think it should be > fd5b08977630. > >> > >> No, it's stable/13-n246157-fd5b0897763 > >> > >> I will give a n246188+ user land a try, and ... > > > > Great. Please do let me know... I started this for compatibility so I > > didn't have > > to keep hacking simple scripts for FreeBSD and if something is screwed = up > > that means it's falling short of the goal... > > > >>> So the change is expected, but if the change to all the *sum programs > is > >>> incompatible still, I know I'd like to know (as I'm sure se@ would as > >>> well). All the *sum programs are very new and designed to be 100% > >>> compatible with the linux versions and if they aren't that needs to b= e > >>> fixed. > >> > >> =E2=80=A6 I will report back. > > > > Excellent! > > I am running stable/13-n246205-9e06b34bb5d, now. > > But I do have to report that rkhunter is still lacking to calculate hashe= s > when using sha256sum instead of sha256. > > In a previous mail you wrote: "I recently added the 'sum' variations". > Does that mean that sha256sum (et al.) didn't exist before? That could > explain why rkhunter didn't fail before. > Yes. It was merged in commit c0d5665be0 on June 28th. > Example output: > > KBN> sha256 crontab.mike > SHA256 (test.dat) =3D > 829f9293639f1a590757bf3eaa369c102b071ef450d3f196e29d5c810f23a2c9 > > KBN> sha256sum test.dat > 829f9293639f1a590757bf3eaa369c102b071ef450d3f196e29d5c810f23a2c9 > test.dat > > If I am not mistaken does rkhunter cut that output string into relevant > junks. In both cases the hash is at different positions, though ... > That output looks right to my eye. I see identical output between my ubuntu VMs and my freebsd box. > > > Sorry for any hassle this work is causing. > > No big deal for rkhunter, a workaround exists ;-) > I think the reason is that it automatically switched to using sha256sum because it was present, but it didn't automatically change #HASH_FLD_IDX=3D= 4 to be 1. The shell script is tricky enough that I've not looked through it all. I'd argue this is a bug in the get_sha_hash_function which doesn't adjust the HASH_FLD_IDX based on which version it finds. Instead, it sets it unconditionally to 4 on *BSD or DragonFly. Warner P.S. I think it needs something like the following updated patch-files_rkhunter and/or changes upstream. I don't know what this port does, apart from what I've just read. Can you see if this fixes this? --00000000000039818805c68dd76b-- --00000000000039818a05c68dd76d-- From nobody Wed Jul 7 20:24: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 9CDE611E2FA9; Wed, 7 Jul 2021 20:24:13 +0000 (UTC) (envelope-from trashcan@ellael.org) Received: from mx2.enfer-du-nord.net (mx2.enfer-du-nord.net [135.125.211.209]) (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 4GKrVj2Rggz3Bvq; Wed, 7 Jul 2021 20:24:12 +0000 (UTC) (envelope-from trashcan@ellael.org) Received: from smtpclient.apple (p200300fb4f0558010938F8309a8230D1.dip0.t-ipconnect.de [IPv6:2003:fb:4f05:5801:938:f830:9a82:30d1]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx2.enfer-du-nord.net (Postfix) with ESMTPSA id 4GKrVd4XLnz1DJ; Wed, 7 Jul 2021 22:24:09 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ellael.org; s=dkim; t=1625689449; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=txTHjwjF1PUp8Egjf9oMd0Lhs2ezEr2SOEGQPFTkoAQ=; b=w9I1dn6Vkj41GFv4xCxL3bK22o+ZkT6ZO3np2bYUrLbi9bQ9gzUj7hf1QtGlZMP4u4dRqe o0yvj1LCxvTz+DAtEsurvsxyMVVHJCeSHGSWoSmdeTREBwixG0/j8cjVFfVxyPyOYhG2s0 c6hTb7XlIvt2u5ULOrFUIp81unnI0S4Q7B+nqsHHBwlMAehWkttPoMv7hWQjDmHZZqpimJ NWhu2G0VuVNbgAFU621/iUjUfZ+3CiREIvuQDLiBdAWf00NsVHpdqPqXF6yT95nPVlfVCf G03GJSKoLPOxi2RY7n52MxT7xnRaa7XGDwGCnXRUGYrZbMLEmKvbDZyyvJDOnQ== Message-Id: <0B2C7AEA-27C6-4259-9DCF-D20C19737A50@ellael.org> Content-Type: multipart/mixed; boundary="Apple-Mail=_D505DE2F-C582-4001-BDE4-19F198707C1B" 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 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Subject: Re: security/rkhunter without hashes after recent STABLE-13 update Date: Wed, 7 Jul 2021 22:24:09 +0200 In-Reply-To: Cc: FreeBSD-STABLE Mailing List , FreeBSD ports , lukasz@wasikowski.net, Stefan Esser To: Warner Losh References: <416D3033-138D-4BBB-84FA-FAEA2944C837@ellael.org> <08637D0D-9D65-4F53-9A64-F4742BA8E415@ellael.org> X-Mailer: Apple Mail (2.3654.100.0.2.22) X-Rspamd-Queue-Id: 4GKrVj2Rggz3Bvq X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: trashcan@ellael.org From: Michael Grimm via freebsd-stable X-Original-From: Michael Grimm X-ThisMailContainsUnwantedMimeParts: Y --Apple-Mail=_D505DE2F-C582-4001-BDE4-19F198707C1B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Warner Losh wrote: >=20 > On Wed, Jul 7, 2021 at 12:47 PM Michael Grimm = wrote: >> Warner Losh wrote: >>> Sorry for any hassle this work is causing. >>=20 >> No big deal for rkhunter, a workaround exists ;-) >=20 > I think the reason is that it automatically switched to using = sha256sum > because it was present, but it didn't automatically change = #HASH_FLD_IDX=3D4 > to be 1. The shell script is tricky enough that I've not looked = through it > all. I'd argue this is a bug in the get_sha_hash_function which = doesn't > adjust the HASH_FLD_IDX based on which version it finds. Instead, it = sets > it unconditionally to 4 on *BSD or DragonFly. >=20 > Warner >=20 > P.S. I think it needs something like the following updated > patch-files_rkhunter and/or changes upstream. I don't know what this = port > does, apart from what I've just read. Can you see if this fixes this? Your rkhunter script seems to be different to mine =E2=80=A6 MWN> patch < rkhunter.diff=20 Hmm... Looks like a unified diff to me=E2=80=A6 The text leading up to this was: =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 |--- files/rkhunter.orig 2018-02-24 16:08:27.000000000 = -0700 |+++ files/rkhunter 2021-07-07 13:38:56.094378000 -0600 =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 Patching file rkhunter using Plan A=E2=80=A6 Hunk #1 succeeded at 4751. Hunk #2 failed at 7525. Hunk #3 succeeded at 19734 (offset 3 lines). Hunk #4 failed at 19810. 2 out of 4 hunks failed--saving rejects to rkhunter.rej done But anyway, you nailed it! That fixes rkhunter. It will now produce = hashes for both /sbin/sha256 and /sbin/sha256sum. The attached patch (diff to new rkhunter script with both succeeding = hunks) will work for the rkhunter-1.4.6 script. Thanks and with kind regards, Michael --Apple-Mail=_D505DE2F-C582-4001-BDE4-19F198707C1B-- From nobody Wed Jul 7 20:35:11 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 AA33511E57CF for ; Wed, 7 Jul 2021 20:35:23 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (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 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GKrlb4CDxz3Fr3 for ; Wed, 7 Jul 2021 20:35:23 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x730.google.com with SMTP id a6so3386678qka.4 for ; Wed, 07 Jul 2021 13:35:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Mt4aGFeJFm0bRlWk0thJbpob1HfBnajMuEKpBs/z9DY=; b=dVwQbD9fkt+7SAoh8ElizcSdW0jVZvHwLCRLoP1v6Mq58Tm6ohTkN6ByxfFH6leDD4 E0Qg40+j8z1+WwdQlDptHjaXziAQm36wKVixfDi+JC6mgjh1VL1XKw+Mh8LPWhDi7kNi VFxmq9Jp+JVWTOzaxMyF0p6nYPDiPjrKj+SajOepODz/lBpW+CSS5ogodH59GZp2eXml 6a5MlHk6SvrSduK4wuozvq5iVi84N7tUMhCBUUvnGRre/j7EqO9BbQJC9b9ju1aqLDgu NO3spl6MkZgZHt1c6gbzifMv5oGBtMpIzf55EIgkrvJviwvwBDWXMPQZ1bFyQczCUksI KUww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Mt4aGFeJFm0bRlWk0thJbpob1HfBnajMuEKpBs/z9DY=; b=p76+/KPCXOSBkn+eFycvH0hDp5K0Vhb1PSOaXxPywkdohAi0zh2XTEQtOXZBmozgSt Ix9W3gqape7BRxbZdIbeDCIILceXANsl/oJCwrCjAEUR2oRHrwhtbVccrw7w+dnFAsEx VIp2Bu7pOlxlet64939Rr/yPsyjUzwoKfnW2eo2IMP1+TH2Fdi48jGmYtI0lRSZn3hWM eyl7t8Dm4tB5B2Fu9F/CS11NU/KSOZPP/9oFXEngWEDhsZzcoYhF2yRdIw0bb8pSfUm+ vzRrs9YBfQvcyaqa/0I1mWaKVXrBEo33puUaeZ6cAN8Ub2NwPsMMYX4O2TGLhCMnP9g9 Fc2Q== X-Gm-Message-State: AOAM5306Chw8pAF0ngeZWMkxfWfUtTYsutX4NO9aTpnuXMLDmLBMYnsK TZv9tJK15x0pH5Xm6uonOSSVjg+LXs+gTsgE5dT3PA== X-Google-Smtp-Source: ABdhPJypEiAD8Wm4PDQuJx1/PlC4mFgkLE428R5ijiwRxcyQhhK4jGXb9TzPrphPatBhpYg4ugDRpyPEceF6AL6MWJc= X-Received: by 2002:a05:620a:8:: with SMTP id j8mr11785801qki.44.1625690122654; Wed, 07 Jul 2021 13:35:22 -0700 (PDT) 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 References: <416D3033-138D-4BBB-84FA-FAEA2944C837@ellael.org> <08637D0D-9D65-4F53-9A64-F4742BA8E415@ellael.org> <0B2C7AEA-27C6-4259-9DCF-D20C19737A50@ellael.org> In-Reply-To: <0B2C7AEA-27C6-4259-9DCF-D20C19737A50@ellael.org> From: Warner Losh Date: Wed, 7 Jul 2021 14:35:11 -0600 Message-ID: Subject: Re: security/rkhunter without hashes after recent STABLE-13 update To: Michael Grimm Cc: FreeBSD-STABLE Mailing List , FreeBSD ports , lukasz@wasikowski.net, Stefan Esser Content-Type: multipart/alternative; boundary="00000000000046a4fd05c68e7ae5" X-Rspamd-Queue-Id: 4GKrlb4CDxz3Fr3 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y --00000000000046a4fd05c68e7ae5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jul 7, 2021 at 2:24 PM Michael Grimm wrote: > Warner Losh wrote: > > > > On Wed, Jul 7, 2021 at 12:47 PM Michael Grimm > wrote: > >> Warner Losh wrote: > > >>> Sorry for any hassle this work is causing. > >> > >> No big deal for rkhunter, a workaround exists ;-) > > > > I think the reason is that it automatically switched to using sha256sum > > because it was present, but it didn't automatically change > #HASH_FLD_IDX=3D4 > > to be 1. The shell script is tricky enough that I've not looked through > it > > all. I'd argue this is a bug in the get_sha_hash_function which doesn't > > adjust the HASH_FLD_IDX based on which version it finds. Instead, it se= ts > > it unconditionally to 4 on *BSD or DragonFly. > > > > Warner > > > > P.S. I think it needs something like the following updated > > patch-files_rkhunter and/or changes upstream. I don't know what this po= rt > > does, apart from what I've just read. Can you see if this fixes this? > > > Your rkhunter script seems to be different to mine =E2=80=A6 > > MWN> patch < rkhunter.diff > Hmm... Looks like a unified diff to me=E2=80=A6 > The text leading up to this was: > =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 > |--- files/rkhunter.orig 2018-02-24 16:08:27.000000000 -07= 00 > |+++ files/rkhunter 2021-07-07 13:38:56.094378000 -0600 > =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 > Patching file rkhunter using Plan A=E2=80=A6 > Hunk #1 succeeded at 4751. > Hunk #2 failed at 7525. > Hunk #3 succeeded at 19734 (offset 3 lines). > Hunk #4 failed at 19810. > 2 out of 4 hunks failed--saving rejects to rkhunter.rej > done > > But anyway, you nailed it! That fixes rkhunter. It will now produce hashe= s > for both /sbin/sha256 and /sbin/sha256sum. > > The attached patch (diff to new rkhunter script with both succeeding > hunks) will work for the rkhunter-1.4.6 script. > Great! I see you've cc'd lukasz. I'll assume that he can commit it, but if there's an issue, please let me know! Warner > Thanks and with kind regards, > Michael > > > --00000000000046a4fd05c68e7ae5-- From nobody Wed Jul 7 21:34:42 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 0714D11F6E4A for ; Wed, 7 Jul 2021 21:34:47 +0000 (UTC) (envelope-from SRS0=EUh4=L7=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4GKt456N6dz3Qg9 for ; Wed, 7 Jul 2021 21:34:45 +0000 (UTC) (envelope-from SRS0=EUh4=L7=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 8F87028417 for ; Wed, 7 Jul 2021 23:34:43 +0200 (CEST) Received: from illbsd.quip.test (ip-94-113-69-69.net.upcbroadband.cz [94.113.69.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id C90BB28411 for ; Wed, 7 Jul 2021 23:34:42 +0200 (CEST) To: FreeBSD Stable Mailing List From: Miroslav Lachman <000.fbsd@quip.cz> Subject: CPU hot-plug and RAM hot-add in virtual machines Message-ID: <4336a1bf-d826-dba3-9ec1-9b48cf7cd177@quip.cz> Date: Wed, 7 Jul 2021 23:34:42 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 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=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4GKt456N6dz3Qg9 X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of SRS0=EUh4=L7=quip.cz=000.fbsd@elsa.codelab.cz has no SPF policy when checking 94.124.105.4) smtp.mailfrom=SRS0=EUh4=L7=quip.cz=000.fbsd@elsa.codelab.cz X-Spamd-Result: default: False [2.95 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; FORGED_SENDER(0.30)[000.fbsd@quip.cz,SRS0=EUh4=L7=quip.cz=000.fbsd@elsa.codelab.cz]; RECEIVED_SPAMHAUS_PBL(0.00)[94.113.69.69:received]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[94.124.105.4:from]; MIME_TRACE(0.00)[0:+]; FROM_NEQ_ENVFROM(0.00)[000.fbsd@quip.cz,SRS0=EUh4=L7=quip.cz=000.fbsd@elsa.codelab.cz]; ASN(0.00)[asn:42000, ipnet:94.124.104.0/21, country:CZ]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_SHORT(0.85)[0.853]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.10)[0.103]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[94.124.105.4:from:127.0.2.255]; DMARC_NA(0.00)[quip.cz]; NEURAL_SPAM_LONG(0.79)[0.793]; R_SPF_NA(0.00)[no SPF record]; MAILMAN_DEST(0.00)[freebsd-stable] X-ThisMailContainsUnwantedMimeParts: N The question is simple but I cannot find answer - Does FreeBSD support hot-plug vCPU and hot-add RAM? Current virtualization platforms support adding CPU cores or additional RAM without the need to reboot the guest OS. Some of our clients need to add additional vCPUs or RAM so often that hot-plug and hot-add will be really useful. If this is not supported on FreeBSD for now, is there any Work In Progress? Or is there a plan to support it? Kind regards Miroslav Lachman From nobody Thu Jul 8 02:29:22 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 2EBA311F7490 for ; Thu, 8 Jul 2021 02:29:37 +0000 (UTC) (envelope-from mike@jellydonut.org) Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (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 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GL0cJ3wYKz4nvt for ; Thu, 8 Jul 2021 02:29:36 +0000 (UTC) (envelope-from mike@jellydonut.org) Received: by mail-ed1-x530.google.com with SMTP id l2so6237489edt.1 for ; Wed, 07 Jul 2021 19:29:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jellydonut-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=omkTXX9/UhQfWX2PE3Fjgr2HzKMg7QlqSv5Dkpkct6o=; b=0BPd94CrpL/Eahi6OthPEYFmmMNmYbZvzjt0SH4QSJHzIjA1Q4MBz25P8sxN3SjJyB cI5thh1NjwLwVtigs6kBB+9Od6ERE5FiimsJGj9gX5ihzcktQozEYORIYIMzkM1vW0Ki //TuCn54MAHHxHJjvSUW+K40a9aumtqsB0evS+g3n95fMWPRULfajHW/NO9CLRZDbdhD +DwTNN4d3wPm3BsC1ZQFEWH0NM9vInp5NgMre6WKcHt+sXi//ujaN451IQbqlEmOFyCB U3xkrfztqhAoaE2PucY9M+3kc058SahmFmrOImtlC1NOo8kamrlRBe3UY83uYiWEqHgz BBhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=omkTXX9/UhQfWX2PE3Fjgr2HzKMg7QlqSv5Dkpkct6o=; b=HvZ/BEFY+M2gx0kD6yM2SpSF86c8pFO/8eicaxkljPWEPy6m3+MBjof6fZwIv6TRdA W4wc7MbtkqJTRXnI9jbUVY7rdfB5+zZxGp3/zCKoIEaw/3C4UdYyQgUe7MH3nqnLkWht 5l9KBwCtOtfn34jNj73IPFLwQXIQ37Urb8otdAQb1AOReZdY0m7TqyUGWsdMWq+m/aGJ 1FkqbDDLAvcg5B+ay36wrGI/MdbRJ0LYJbxmhcAk0JRLbOFTNVl8maho+gQauHoSPWrF fpV9ZyQ4sOYNgYpetRdzf1d4O431pClDZMK3YnHHql216zCOLAXN7Wh5WuKlaAiqBNm1 mXPg== X-Gm-Message-State: AOAM5303929pfqokxNj340RNvJNHzCTAPCK2KZyKIxYSeWrrqes/B0sX ko5V7G3dIBqTle5vuLt/JpHQaKKwg1OmlqiOnBFPmB7sVWCyzv9y X-Google-Smtp-Source: ABdhPJxb3/fzBpKi8IBXfHdCxLCUaFZq6bOgl6I1V9xHyBVSq4cHLI0zaPphN5GjrFqWdSKw9Ny3nzdWhvuNHgj9SMw= X-Received: by 2002:aa7:c918:: with SMTP id b24mr27110536edt.132.1625711373347; Wed, 07 Jul 2021 19:29:33 -0700 (PDT) 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 References: In-Reply-To: From: Michael Proto Date: Wed, 7 Jul 2021 22:29:22 -0400 Message-ID: Subject: Re: 13.0-RELEASEp3 info? To: FreeBSD-STABLE Mailing List Content-Type: multipart/alternative; boundary="000000000000ea7cbc05c6936c2c" X-Rspamd-Queue-Id: 4GL0cJ3wYKz4nvt X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=pass header.d=jellydonut-org.20150623.gappssmtp.com header.s=20150623 header.b=0BPd94Cr; dmarc=none; spf=pass (mx1.freebsd.org: domain of mike@jellydonut.org designates 2a00:1450:4864:20::530 as permitted sender) smtp.mailfrom=mike@jellydonut.org X-Spamd-Result: default: False [1.49 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[jellydonut-org.20150623.gappssmtp.com:s=20150623]; FREEFALL_USER(0.00)[mike]; FROM_HAS_DN(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[2a00:1450:4864:20::530:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; DMARC_NA(0.00)[jellydonut.org]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[2a00:1450:4864:20::530:from:127.0.2.255]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[jellydonut-org.20150623.gappssmtp.com:+]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::530:from]; NEURAL_SPAM_SHORT(0.97)[0.969]; NEURAL_HAM_LONG(-0.98)[-0.976]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-stable] X-ThisMailContainsUnwantedMimeParts: Y --000000000000ea7cbc05c6936c2c Content-Type: text/plain; charset="UTF-8" On Sat, Jul 3, 2021 at 4:38 AM Rainer Duffner wrote: > > > Am 03.07.2021 um 04:56 schrieb Michael Proto : > > So recently I ran freebsd-update on my 13.0-RELEASE hosts and received and > applied updates for 13.0-RELEASEp3, although I've yet to see a security or > advisory announcement, nor anything on the errata page. Am I missing > something? Last I checked I was subscribed and I did get notifications for > 13.0-RELEASEp2. > > > > > This one, I assume: > > > https://www.freebsd.org/security/advisories/FreeBSD-EN-21:22.linux_futex.asc > > > > Thanks for that, now to figure out why I didn't get (or otherwise filtered) that announcement. Much appreciated. --000000000000ea7cbc05c6936c2c-- From nobody Thu Jul 8 08:25:55 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 B7CD0122F652; Thu, 8 Jul 2021 08:25:58 +0000 (UTC) (envelope-from lukasz@wasikowski.net) Received: from mail.freebsd.systems (mail.freebsd.systems [5.196.167.1]) (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 4GL8WV40hRz3phY; Thu, 8 Jul 2021 08:25:57 +0000 (UTC) (envelope-from lukasz@wasikowski.net) Received: from mail.freebsd.systems (mail.freebsd.systems [IPv6:2001:41d0:a:71bf::1]) by mail.freebsd.systems (Postfix) with ESMTP id 99EF61DEC2; Thu, 8 Jul 2021 10:25:55 +0200 (CEST) X-Virus-Scanned: amavisd-new at freebsd.systems Received: from mail.freebsd.systems ([5.196.167.1]) by mail.freebsd.systems (scan.freebsd.systems [5.196.167.1]) (amavisd-new, port 10026) with ESMTP id 85n_KnvjRlHu; Thu, 8 Jul 2021 10:25:55 +0200 (CEST) Received: from [192.168.168.3] (89-70-50-99.dynamic.chello.pl [89.70.50.99]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.freebsd.systems (Postfix) with ESMTPSA id 32C841DD70; Thu, 8 Jul 2021 10:25:55 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wasikowski.net; s=default; t=1625732755; bh=e9VqsPM3whcy2lR8j99UNL38Q9Th3IbijLloMHrsOis=; h=To:Cc:References:From:Date:In-Reply-To; b=uMfyf40D2qqHMTFngE/NCR5cntUigkNGIhS2dJHjNU2oq+/PDFXOE7lWDjyLM36ui zF5bMTdmxzdHoDyf0haKNPBixD9fQy37x54dgqozFHX363UaAXu2XHKoqBaWXuqZXO 6kXTGcGkad6S1JpcsNhajAyJ2BaOIZ+1n15trxnzFZPe6Xch7KMobKDbK/V67MZyf2 5tcQe4fcNNKiEUM9f05pYdSagFVXYlJJ3YbXSpTD0o+vRE5BBYYztML88LOPKtX3xJ dvTFq1WW0kEDTFQfmUXEkv61sx3jHHNhjvSQmZBQuDZyNblG0ecB2BsMc6GnetDBYJ laESezA+CtwbQ== Subject: Re: security/rkhunter without hashes after recent STABLE-13 update To: Warner Losh , Michael Grimm Cc: FreeBSD-STABLE Mailing List , FreeBSD ports , Stefan Esser References: <416D3033-138D-4BBB-84FA-FAEA2944C837@ellael.org> <08637D0D-9D65-4F53-9A64-F4742BA8E415@ellael.org> <0B2C7AEA-27C6-4259-9DCF-D20C19737A50@ellael.org> From: =?UTF-8?Q?=c5=81ukasz_W=c4=85sikowski?= Message-ID: Date: Thu, 8 Jul 2021 10:25:55 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 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 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: pl Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4GL8WV40hRz3phY X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N W dniu 2021-07-07 o 22:35, Warner Losh pisze: > The attached patch (diff to new rkhunter script with both succeeding > hunks) will work for the rkhunter-1.4.6 script. > > > Great! I see you've cc'd lukasz. I'll assume that he can commit it, but > if there's an issue, please let me know! This patch breaks rkhunter on 12.2-RELEASE, hashes are not calculated. -- Best regards, Łukasz Wąsikowski From nobody Thu Jul 8 09:17:07 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 419818D6251; Thu, 8 Jul 2021 09:17:09 +0000 (UTC) (envelope-from se@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b: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 (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GL9fY17rmz4Qll; Thu, 8 Jul 2021 09:17:09 +0000 (UTC) (envelope-from se@freebsd.org) Received: from Stefans-MBP-449.fritz.box (p200300cd5f1f2f007ca904cdc22dde0c.dip0.t-ipconnect.de [IPv6:2003:cd:5f1f:2f00:7ca9:4cd:c22d:de0c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: se/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 527E42D5CD; Thu, 8 Jul 2021 09:17:08 +0000 (UTC) (envelope-from se@freebsd.org) From: Stefan Esser To: Michael Grimm , Warner Losh Cc: FreeBSD-STABLE Mailing List , FreeBSD ports , lukasz@wasikowski.net References: <416D3033-138D-4BBB-84FA-FAEA2944C837@ellael.org> <08637D0D-9D65-4F53-9A64-F4742BA8E415@ellael.org> <0B2C7AEA-27C6-4259-9DCF-D20C19737A50@ellael.org> Subject: security/rkhunter without hashes after recent STABLE-13 update Message-ID: <4355013a-0be1-829f-2fe5-86eeb4ba80f7@freebsd.org> Date: Thu, 8 Jul 2021 11:17:07 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 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 In-Reply-To: <0B2C7AEA-27C6-4259-9DCF-D20C19737A50@ellael.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="GxeD6L2ZH33KPpGC8vsNLNvpZgPiZw8R2" X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --GxeD6L2ZH33KPpGC8vsNLNvpZgPiZw8R2 Content-Type: multipart/mixed; boundary="PhEMBSXfMc8zoSFWPwaQWT8IQX0EdkuQ7"; protected-headers="v1" From: Stefan Esser To: Michael Grimm , Warner Losh Cc: FreeBSD-STABLE Mailing List , FreeBSD ports , lukasz@wasikowski.net Message-ID: <4355013a-0be1-829f-2fe5-86eeb4ba80f7@freebsd.org> Subject: security/rkhunter without hashes after recent STABLE-13 update References: <416D3033-138D-4BBB-84FA-FAEA2944C837@ellael.org> <08637D0D-9D65-4F53-9A64-F4742BA8E415@ellael.org> <0B2C7AEA-27C6-4259-9DCF-D20C19737A50@ellael.org> In-Reply-To: <0B2C7AEA-27C6-4259-9DCF-D20C19737A50@ellael.org> --PhEMBSXfMc8zoSFWPwaQWT8IQX0EdkuQ7 Content-Type: multipart/mixed; boundary="------------F0E6835EAC1DDC280EA83B43" Content-Language: en-US This is a multi-part message in MIME format. --------------F0E6835EAC1DDC280EA83B43 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Am 07.07.21 um 22:24 schrieb Michael Grimm: > Warner Losh wrote: >> >> On Wed, Jul 7, 2021 at 12:47 PM Michael Grimm wr= ote: >>> Warner Losh wrote: >=20 >>>> Sorry for any hassle this work is causing. >>> >>> No big deal for rkhunter, a workaround exists ;-) >> >> I think the reason is that it automatically switched to using sha256su= m >> because it was present, but it didn't automatically change #HASH_FLD_I= DX=3D4 >> to be 1. The shell script is tricky enough that I've not looked throug= h it >> all. I'd argue this is a bug in the get_sha_hash_function which doesn'= t >> adjust the HASH_FLD_IDX based on which version it finds. Instead, it s= ets >> it unconditionally to 4 on *BSD or DragonFly. [...] >=20 > But anyway, you nailed it! That fixes rkhunter. It will now produce has= hes for both /sbin/sha256 and /sbin/sha256sum. >=20 > The attached patch (diff to new rkhunter script with both succeeding hu= nks) will work for the rkhunter-1.4.6 script. >=20 > Thanks and with kind regards, > Michael Hi Warner and Michael, the reason I added full support for the -c option was that a port build f= ailed since it assumed that if the name of the hash program ended in "sum" it w= as fully compatible with the Coreutils program of that name and that is supp= orted the "-c digestfile" option. This is a general problem when we gain compatibility with some other OS (= TM): Ports often assume that availability of a program (MACRO, include file, .= =2E.) means it is the real thing, and not only attempt of an emulation of the m= ost important feature (i.e. only considering a very specific use case). An alternative (and my preferred fix) would be to not search for the *sum= functions on FreeBSD, and thus not having to adjust the HASH_FLD_IDX vari= able: -- files/rkhunter.orig 2018-02-24 23:08:27 UTC +++ files/rkhunter @@ -4750,7 +4750,12 @@ get_sha_hash_function() { return fi - HFUNC=3D`find_cmd sha${SHA_SIZE}sum` + case ${OPERATING_SYSTEM} in + FreeBSD) + HFUNC=3D`find_cmd sha${SHA_SIZE}` ;; + *) + HFUNC=3D`find_cmd sha${SHA_SIZE}sum` ;; + esac if [ -z "${HFUNC}" ]; then HFUNC=3D`find_cmd sha${SHA_SIZE}` The suggested patch is attached. I did not want to change more lines than= required, and other BSDs could easily added to the special case, should they be affected, too. And I'd assume that this patch could be accepted by the upstream ... Michael, could you please test this patch? (I do not have rkhunter installed on my system ...) Regards, STefan --------------F0E6835EAC1DDC280EA83B43 Content-Type: text/plain; charset=UTF-8; x-mac-type="0"; x-mac-creator="0"; name="rkhunter-port.diff" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="rkhunter-port.diff" ZGlmZiAtLWdpdCBhL3NlY3VyaXR5L3JraHVudGVyL2ZpbGVzL3BhdGNoLWZpbGVzX3JraHVu dGVyIGIvc2VjdXJpdHkvcmtodW50ZXIvZmlsZXMvcGF0Y2gtZmlsZXNfcmtodW50ZXIKaW5k ZXggYmQ3MGMzYTI3NmY0Li42MTZjNTg5YWUxMTIgMTAwNjQ0Ci0tLSBhL3NlY3VyaXR5L3Jr aHVudGVyL2ZpbGVzL3BhdGNoLWZpbGVzX3JraHVudGVyCisrKyBiL3NlY3VyaXR5L3JraHVu dGVyL2ZpbGVzL3BhdGNoLWZpbGVzX3JraHVudGVyCkBAIC0xLDYgKzEsMjAgQEAKLS0tLSBm aWxlcy9ya2h1bnRlci5vcmlnCTIwMTQtMDMtMTIgMjA6NTQ6NTUgVVRDCistLS0gZmlsZXMv cmtodW50ZXIub3JpZwkyMDE4LTAyLTI0IDIzOjA4OjI3IFVUQwogKysrIGZpbGVzL3JraHVu dGVyCi1AQCAtNzI3NSw2ICs3Mjc1LDkgQEAgZG93bmxvYWRfZmlsZSgpIHsKK0BAIC00NzUw LDcgKzQ3NTAsMTIgQEAgZ2V0X3NoYV9oYXNoX2Z1bmN0aW9uKCkgeworIAkJcmV0dXJuCisg CWZpCisgCistCUhGVU5DPWBmaW5kX2NtZCBzaGEke1NIQV9TSVpFfXN1bWAKKysJY2FzZSAk e09QRVJBVElOR19TWVNURU19IGluCisrCUZyZWVCU0QpCisrCQlIRlVOQz1gZmluZF9jbWQg c2hhJHtTSEFfU0laRX1gIDs7CisrCSopCisrCQlIRlVOQz1gZmluZF9jbWQgc2hhJHtTSEFf U0laRX1zdW1gIDs7CisrCWVzYWMKKyAKKyAJaWYgWyAteiAiJHtIRlVOQ30iIF07IHRoZW4K KyAJCUhGVU5DPWBmaW5kX2NtZCBzaGEke1NIQV9TSVpFfWAKK0BAIC03NTIyLDYgKzc1Mjcs OSBAQCBkb3dubG9hZF9maWxlKCkgewogIAkJcm0gLWYgIiR7T1VUUFVUX0ZJTEV9IiA+L2Rl di9udWxsIDI+JjEKICAKICAJCWNhc2UgIiR7UktIV0VCQ01EX0JBU0V9IiBpbgo= --------------F0E6835EAC1DDC280EA83B43-- --PhEMBSXfMc8zoSFWPwaQWT8IQX0EdkuQ7-- --GxeD6L2ZH33KPpGC8vsNLNvpZgPiZw8R2 Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEo3HqZZwL7MgrcVMTR+u171r99UQFAmDmwpMFAwAAAAAACgkQR+u171r99URI HAgAlv+3InNypIQjAxvqXgljkWRUZRx/lA5NH+cxeV9pSpY1vUNzrw7HoTUo63MJAZnscYVBgnCR U8ErDCbS27iyQAakgdNMOpFSu7GcMJfxWg9ykfpKtt9toPJksx0wrUTjV8rBZwl7fNBGfnzmNa41 EcsHQWS/uTw7BFBcEX73YH3cT8gr+KOeXYeS2RWNoQ6vXt/UOAlt50sBLgAjnxkFJWqrRK+nStfh 46KnNZ9/NCfy7SivXnd0mE5ztl+IyOCm2Dj+BOgEmqvJCV7+v2FnXlHFlWPQV3Civ65yEEkohEWD g1JkfU3CHk3/jih/y6wDyu11Yk6MGyQaP0hV6U6ESQ== =Ol13 -----END PGP SIGNATURE----- --GxeD6L2ZH33KPpGC8vsNLNvpZgPiZw8R2-- From nobody Thu Jul 8 12:16:44 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 24F53122774C; Thu, 8 Jul 2021 12:16:48 +0000 (UTC) (envelope-from trashcan@ellael.org) Received: from mx2.enfer-du-nord.net (mx2.enfer-du-nord.net [IPv6:2001:41d0:701:1000::1685]) (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 4GLFdq6yv5z4pxq; Thu, 8 Jul 2021 12:16:47 +0000 (UTC) (envelope-from trashcan@ellael.org) Received: from smtpclient.apple (p200300FB4F03f5013d64EC276C99a51F.dip0.t-ipconnect.de [IPv6:2003:fb:4f03:f501:3d64:ec27:6c99:a51f]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx2.enfer-du-nord.net (Postfix) with ESMTPSA id 4GLFdm5t1Yz6jd; Thu, 8 Jul 2021 14:16:44 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ellael.org; s=dkim; t=1625746604; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=wqzz6QbVDXeMjJ3ZuLP69RKqgsI5cOcEOzjr1QgyLbs=; b=bgdVigHaUv6KY8OOvRAPIKtRXyawJaRcLWcpIviBENWgjjlhBOH48gBSvwspCBbkVQHgmt 1IHR7VCRRf0d5C+Q8pDI4YZhaNyXbP08FqXGzb8jYCisd6wOytrVJLpqROh6+J42AfyArc zbvCWEjbGKzg1NQzmGGEeCXENec/FptS6fr1fxaT6FTIkmsJwTN9qdSa/4Bm7BttTkJD+k 4fUdO1w57QcNJpMjS53hA2e/p+IdlTlcGbjetWpbBLvFltmxb29h+PL42rfUH8JlEFIyJM 8TSie4uRkbDh8bvw2aMYqGRi5b+A2OODlmv80Y0CBB9j5sHfx7y0UTxNP1nIJg== Content-Type: text/plain; charset=utf-8 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 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Subject: Re: security/rkhunter without hashes after recent STABLE-13 update In-Reply-To: <4355013a-0be1-829f-2fe5-86eeb4ba80f7@freebsd.org> Date: Thu, 8 Jul 2021 14:16:44 +0200 Cc: Warner Losh , FreeBSD-STABLE Mailing List , FreeBSD ports , lukasz@wasikowski.net Content-Transfer-Encoding: quoted-printable Message-Id: References: <416D3033-138D-4BBB-84FA-FAEA2944C837@ellael.org> <08637D0D-9D65-4F53-9A64-F4742BA8E415@ellael.org> <0B2C7AEA-27C6-4259-9DCF-D20C19737A50@ellael.org> <4355013a-0be1-829f-2fe5-86eeb4ba80f7@freebsd.org> To: Stefan Esser X-Mailer: Apple Mail (2.3654.100.0.2.22) X-Rspamd-Queue-Id: 4GLFdq6yv5z4pxq X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: trashcan@ellael.org From: Michael Grimm via freebsd-stable X-Original-From: Michael Grimm X-ThisMailContainsUnwantedMimeParts: N Hi Stefan, Stefan Esser wrote > Am 07.07.21 um 22:24 schrieb Michael Grimm: >> Warner Losh wrote: >>> On Wed, Jul 7, 2021 at 12:47 PM Michael Grimm = wrote: >>>> Warner Losh wrote: >>>>> Sorry for any hassle this work is causing. >>>>=20 >>>> No big deal for rkhunter, a workaround exists ;-) >>>=20 >>> I think the reason is that it automatically switched to using = sha256sum >>> because it was present, but it didn't automatically change = #HASH_FLD_IDX=3D4 >>> to be 1. The shell script is tricky enough that I've not looked = through it >>> all. I'd argue this is a bug in the get_sha_hash_function which = doesn't >>> adjust the HASH_FLD_IDX based on which version it finds. Instead, it = sets >>> it unconditionally to 4 on *BSD or DragonFly. > [...] >>=20 >> But anyway, you nailed it! That fixes rkhunter. It will now produce = hashes for both /sbin/sha256 and /sbin/sha256sum. >>=20 >> The attached patch (diff to new rkhunter script with both succeeding = hunks) will work for the rkhunter-1.4.6 script. >=20 > Hi Warner and Michael, >=20 > the reason I added full support for the -c option was that a port = build failed > since it assumed that if the name of the hash program ended in "sum" = it was > fully compatible with the Coreutils program of that name and that is = supported > the "-c digestfile" option. >=20 > This is a general problem when we gain compatibility with some other = OS (TM): > Ports often assume that availability of a program (MACRO, include = file, ...) > means it is the real thing, and not only attempt of an emulation of = the most > important feature (i.e. only considering a very specific use case). >=20 > An alternative (and my preferred fix) would be to not search for the = *sum > functions on FreeBSD, and thus not having to adjust the HASH_FLD_IDX = variable: >=20 > -- files/rkhunter.orig 2018-02-24 23:08:27 UTC > +++ files/rkhunter > @@ -4750,7 +4750,12 @@ get_sha_hash_function() { > return > fi >=20 > - HFUNC=3D`find_cmd sha${SHA_SIZE}sum` > + case ${OPERATING_SYSTEM} in > + FreeBSD) > + HFUNC=3D`find_cmd sha${SHA_SIZE}` ;; > + *) > + HFUNC=3D`find_cmd sha${SHA_SIZE}sum` ;; > + esac >=20 > if [ -z "${HFUNC}" ]; then > HFUNC=3D`find_cmd sha${SHA_SIZE}` >=20 > The suggested patch is attached. I did not want to change more lines = than > required, and other BSDs could easily added to the special case, = should > they be affected, too. >=20 > And I'd assume that this patch could be accepted by the upstream ... >=20 > Michael, could you please test this patch? I can confirm that your patch works perfectly well.=20 No more workaround needed, now rkhunter calculates sha256 hashes as = usual. Thanks for that.=20 Now, =C5=81ukasz need's to confirm that rkhunter at 12.2-RELEASE will = calculate those hashes as well. Regards, Michael= From nobody Thu Jul 8 21:38:35 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 296D612287B4 for ; Thu, 8 Jul 2021 21:39:13 +0000 (UTC) (envelope-from karl@denninger.net) Received: from colo1.denninger.net (colo1.denninger.net [104.236.120.189]) (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 4GLV6m2cySz3FHh for ; Thu, 8 Jul 2021 21:39:12 +0000 (UTC) (envelope-from karl@denninger.net) Received: from denninger.net (096-033-205-208.res.spectrum.com [96.33.205.208]) by colo1.denninger.net (Postfix) with ESMTP id F302A2110A5 for ; Thu, 8 Jul 2021 17:38:34 -0400 (EDT) Received: from [192.168.10.25] (D15.Denninger.Net [192.168.10.25]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by denninger.net (Postfix) with ESMTPSA id 5E62D356F50 for ; Thu, 8 Jul 2021 17:38:35 -0400 (EDT) To: FreeBSD-STABLE Mailing List From: Karl Denninger Subject: 12.2 Splay Tree ipfw potential panic source Message-ID: <2e3dcd4d-c8e6-8381-0010-d0844c99901e@denninger.net> Date: Thu, 8 Jul 2021 17:38:35 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 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: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms090602070707090905050503" X-Rspamd-Queue-Id: 4GLV6m2cySz3FHh X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=denninger.net; spf=pass (mx1.freebsd.org: domain of karl@denninger.net designates 104.236.120.189 as permitted sender) smtp.mailfrom=karl@denninger.net X-Spamd-Result: default: False [-5.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; HAS_ATTACHMENT(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[denninger.net,none]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[104.236.120.189:from]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:14061, ipnet:104.236.64.0/18, country:US]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.10)[-0.099]; FREEFALL_USER(0.00)[karl]; FROM_HAS_DN(0.00)[]; SIGNED_SMIME(-2.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,multipart/alternative,text/plain]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:~]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[104.236.120.189:from:127.0.2.255]; MAILMAN_DEST(0.00)[freebsd-stable] X-ThisMailContainsUnwantedMimeParts: Y This is a cryptographically signed message in MIME format. --------------ms090602070707090905050503 Content-Type: multipart/alternative; boundary="------------5574490AF6C2ED16FA45726C" Content-Language: en-US This is a multi-part message in MIME format. --------------5574490AF6C2ED16FA45726C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable This is the only change I'm aware of in the build I just put on a=20 firewall that uses ipfw heavily, and it is not panic'ing quite regularly.= Same build, stable/12-n233371-c3e6df3967f, works fine without ipfw in=20 active use on a different machine. I'll see if I can get a dump from it but that may be difficult as the=20 machine in question is a "small box" without attached storage (boots=20 from an SD card.) Just wanted to put a heads-up out there as this was just MFCd according=20 to what saw on the lists a couple of days ago... --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------5574490AF6C2ED16FA45726C-- --------------ms090602070707090905050503 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC DdgwggagMIIEiKADAgECAhMA5EiKghDOXrvfxYxjITXYDdhIMA0GCSqGSIb3DQEBCwUAMIGL MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJTmljZXZpbGxlMRkw FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExITAf BgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQTAeFw0xNzA4MTcxNjQyMTdaFw0yNzA4 MTUxNjQyMTdaMHsxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkwFwYDVQQKDBBD dWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExJTAjBgNVBAMMHEN1 ZGEgU3lzdGVtcyBMTEMgMjAxNyBJbnQgQ0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQC1aJotNUI+W4jP7xQDO8L/b4XiF4Rss9O0B+3vMH7Njk85fZ052QhZpMVlpaaO+sCI KqG3oNEbuOHzJB/NDJFnqh7ijBwhdWutdsq23Ux6TvxgakyMPpT6TRNEJzcBVQA0kpby1DVD 0EKSK/FrWWBiFmSxg7qUfmIq/mMzgE6epHktyRM3OGq3dbRdOUgfumWrqHXOrdJz06xE9NzY vc9toqZnd79FUtE/nSZVm1VS3Grq7RKV65onvX3QOW4W1ldEHwggaZxgWGNiR/D4eosAGFxn uYeWlKEC70c99Mp1giWux+7ur6hc2E+AaTGh+fGeijO5q40OGd+dNMgK8Es0nDRw81lRcl24 SWUEky9y8DArgIFlRd6d3ZYwgc1DMTWkTavx3ZpASp5TWih6yI8ACwboTvlUYeooMsPtNa9E 6UQ1nt7VEi5syjxnDltbEFoLYcXBcqhRhFETJe9CdenItAHAtOya3w5+fmC2j/xJz29og1KH YqWHlo3Kswi9G77an+zh6nWkMuHs+03DU8DaOEWzZEav3lVD4u76bKRDTbhh0bMAk4eXriGL h4MUoX3Imfcr6JoyheVrAdHDL/BixbMH1UUspeRuqQMQ5b2T6pabXP0oOB4FqldWiDgJBGRd zWLgCYG8wPGJGYgHibl5rFiI5Ix3FQncipc6SdUzOQIDAQABo4IBCjCCAQYwHQYDVR0OBBYE FF3AXsKnjdPND5+bxVECGKtc047PMIHABgNVHSMEgbgwgbWAFBu1oRhUMNEzjODolDka5k4Q EDBioYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJ TmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5 c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYIJAKxAy1WBo2kY MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3DQEBCwUAA4IC AQCB5686UCBVIT52jO3sz9pKuhxuC2npi8ZvoBwt/IH9piPA15/CGF1XeXUdu2qmhOjHkVLN gO7XB1G8CuluxofOIUce0aZGyB+vZ1ylHXlMeB0R82f5dz3/T7RQso55Y2Vog2Zb7PYTC5B9 oNy3ylsnNLzanYlcW3AAfzZcbxYuAdnuq0Im3EpGm8DoItUcf1pDezugKm/yKtNtY6sDyENj tExZ377cYA3IdIwqn1Mh4OAT/Rmh8au2rZAo0+bMYBy9C11Ex0hQ8zWcvPZBDn4v4RtO8g+K uQZQcJnO09LJNtw94W3d2mj4a7XrsKMnZKvm6W9BJIQ4Nmht4wXAtPQ1xA+QpxPTmsGAU0Cv HmqVC7XC3qxFhaOrD2dsvOAK6Sn3MEpH/YrfYCX7a7cz5zW3DsJQ6o3pYfnnQz+hnwLlz4MK 17NIA0WOdAF9IbtQqarf44+PEyUbKtz1r0KGeGLs+VGdd2FLA0e7yuzxJDYcaBTVwqaHhU2/ Fna/jGU7BhrKHtJbb/XlLeFJ24yvuiYKpYWQSSyZu1R/gvZjHeGb344jGBsZdCDrdxtQQcVA 6OxsMAPSUPMrlg9LWELEEYnVulQJerWxpUecGH92O06wwmPgykkz//UmmgjVSh7ErNvL0lUY UMfunYVO/O5hwhW+P4gviCXzBFeTtDZH259O7TCCBzAwggUYoAMCAQICEwCg0WvVwekjGFiO 62SckFwepz0wDQYJKoZIhvcNAQELBQAwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3Jp ZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBD QTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExMQyAyMDE3IEludCBDQTAeFw0xNzA4MTcyMTIx MjBaFw0yMjA4MTYyMTIxMjBaMFcxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkw FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRswGQYDVQQDDBJrYXJsQGRlbm5pbmdlci5uZXQw ggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQC+HVSyxVtJhy3Ohs+PAGRuO//Dha9A 16l5FPATr6wude9zjX5f2lrkRyU8vhCXTZW7WbvWZKpcZ8r0dtZmiK9uF58Ec6hhvfkxJzbg 96WHBw5Fumd5ahZzuCJDtCAWW8R7/KN+zwzQf1+B3MVLmbaXAFBuKzySKhKMcHbK3/wjUYTg y+3UK6v2SBrowvkUBC+jxNg3Wy12GsTXcUS/8FYIXgVVPgfZZrbJJb5HWOQpvvhILpPCD3xs YJFNKEPltXKWHT7Qtc2HNqikgNwj8oqOb+PeZGMiWapsatKm8mxuOOGOEBhAoTVTwUHlMNTg 6QUCJtuWFCK38qOCyk9Haj+86lUU8RG6FkRXWgMbNQm1mWREQhw3axgGLSntjjnznJr5vsvX SYR6c+XKLd5KQZcS6LL8FHYNjqVKHBYM+hDnrTZMqa20JLAF1YagutDiMRURU23iWS7bA9tM cXcqkclTSDtFtxahRifXRI7Epq2GSKuEXe/1Tfb5CE8QsbCpGsfSwv2tZ/SpqVG08MdRiXxN 5tmZiQWo15IyWoeKOXl/hKxA9KPuDHngXX022b1ly+5ZOZbxBAZZMod4y4b4FiRUhRI97r9l CxsP/EPHuuTIZ82BYhrhbtab8HuRo2ofne2TfAWY2BlA7ExM8XShMd9bRPZrNTokPQPUCWCg CdIATQIDAQABo4IBzzCCAcswPAYIKwYBBQUHAQEEMDAuMCwGCCsGAQUFBzABhiBodHRwOi8v b2NzcC5jdWRhc3lzdGVtcy5uZXQ6ODg4ODAJBgNVHRMEAjAAMBEGCWCGSAGG+EIBAQQEAwIF oDAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMDMGCWCG SAGG+EIBDQQmFiRPcGVuU1NMIEdlbmVyYXRlZCBDbGllbnQgQ2VydGlmaWNhdGUwHQYDVR0O BBYEFLElmNWeVgsBPe7O8NiBzjvjYnpRMIHKBgNVHSMEgcIwgb+AFF3AXsKnjdPND5+bxVEC GKtc047PoYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UE BwwJTmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRh IFN5c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYITAORIioIQ zl6738WMYyE12A3YSDAdBgNVHREEFjAUgRJrYXJsQGRlbm5pbmdlci5uZXQwDQYJKoZIhvcN AQELBQADggIBAJXboPFBMLMtaiUt4KEtJCXlHO/3ZzIUIw/eobWFMdhe7M4+0u3te0sr77QR dcPKR0UeHffvpth2Mb3h28WfN0FmJmLwJk+pOx4u6uO3O0E1jNXoKh8fVcL4KU79oEQyYkbu 2HwbXBU9HbldPOOZDnPLi0whi/sbFHdyd4/w/NmnPgzAsQNZ2BYT9uBNr+jZw4SsluQzXG1X lFL/qCBoi1N2mqKPIepfGYF6drbr1RnXEJJsuD+NILLooTNf7PMgHPZ4VSWQXLNeFfygoOOK FiO0qfxPKpDMA+FHa8yNjAJZAgdJX5Mm1kbqipvb+r/H1UAmrzGMbhmf1gConsT5f8KU4n3Q IM2sOpTQe7BoVKlQM/fpQi6aBzu67M1iF1WtODpa5QUPvj1etaK+R3eYBzi4DIbCIWst8MdA 1+fEeKJFvMEZQONpkCwrJ+tJEuGQmjoQZgK1HeloepF0WDcviiho5FlgtAij+iBPtwMuuLiL shAXA5afMX1hYM4l11JXntle12EQFP1r6wOUkpOdxceCcMVDEJBBCHW2ZmdEaXgAm1VU+fnQ qS/wNw/S0X3RJT1qjr5uVlp2Y0auG/eG0jy6TT0KzTJeR9tLSDXprYkN2l/Qf7/nT6Q03qyE QnnKiBXWAZXveafyU/zYa7t3PTWFQGgWoC4w6XqgPo4KV44OMYIFBzCCBQMCAQEwgZIwezEL MAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBM TEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExM QyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTANBglghkgBZQMEAgMFAKCCAkUw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjEwNzA4MjEzODM1 WjBPBgkqhkiG9w0BCQQxQgRALyMfcDrkDUazEomEig9v1eaPS7zkr1CGG8fBD3L5ZAyrfyoc QQilU0zaPVPVRChPLD4vk8kvyIpI40melb0wazBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFl AwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3 DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGjBgkrBgEEAYI3EAQxgZUwgZIwezEL MAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBM TEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExM QyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTCBpQYLKoZIhvcNAQkQAgsxgZWg gZIwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lz dGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0 ZW1zIExMQyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTANBgkqhkiG9w0BAQEF AASCAgAzyGuOd+L4FkcONsTUokS7JTp+RDxBRaz5yKKlbNfs9PiukQdWbzHt4kcKroorwMbP SeLn3/mF98pxg2TPq4/D2+IsIF0NplXrEop+K55zSnQr6xYr5pSRgx82vhJ2jkwemyCb4kvK Fz8XQPq9J6GTMgYvxB2gbI2tWCH0ZdzogPRqDFNR9w2QJAK1CvsDzynO7AoO1XXhdZ4y2rv0 dr2r6ZWpPostuda0+8J3ad0KKc6DopuxgRCaUmO3YJ6LoKtQZ1mJLc2IC6ZBlqOehIxCgoup FaFAxiRojiLXEzLAJF0yvHHqUbqyIsIoLRRa4i8k1RX1tGS2RsomOgxlmbNFjio+bxnnsyrm PHVn1dD+HouAaNfFi9EVNZPdCf9/x8xGSGRHT634N1UYyRArH44Bj31duNwqke3Ckjq47DSq DDJfeOQ/360nj4ZFnYYSctvweYIG56TuPSenT3IuWEPf2q75eC2CNizbhvqeWLGTgqHSOJDP 7nbrrQWp1t26uVIMj0UNFXOH8i3f9ZBsNDNZ5XgW5orh5TMESmrdA/z9NemChmLdrp1MrXB9 bGS3lbvHReDlaPxPUON/gzBMli//yJUz46EnyzzXiENoiv67bE1zLeSl0Zz7bJrnl8btdaa5 GQEl2JTta9lUKwXfLEYWFcj31i+y9OjIMaUjOVa1rAAAAAAAAA== --------------ms090602070707090905050503-- From nobody Thu Jul 8 22:11:34 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 0D2F7122DE00 for ; Thu, 8 Jul 2021 22:11:56 +0000 (UTC) (envelope-from lutz@iks-jena.de) Received: from annwfn.iks-jena.de (annwfn.iks-jena.de [IPv6:2001:4bd8::19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4GLVrW5gTHz3LZK for ; Thu, 8 Jul 2021 22:11:55 +0000 (UTC) (envelope-from lutz@iks-jena.de) X-SMTP-Sender: IPv6:2001:4bd8:0:666:248:54ff:fe12:ee3f Received: from belenus.iks-jena.de (belenus.iks-jena.de [IPv6:2001:4bd8:0:666:248:54ff:fe12:ee3f]) by annwfn.iks-jena.de (8.15.2/8.15.2) with ESMTPS id 168MBZXZ003130 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 9 Jul 2021 00:11:35 +0200 X-MSA-Host: belenus.iks-jena.de Received: (from lutz@localhost) by belenus.iks-jena.de (8.14.3/8.14.1/Submit) id 168MBYFA000362; Fri, 9 Jul 2021 00:11:34 +0200 Date: Fri, 9 Jul 2021 00:11:34 +0200 From: Lutz Donnerhacke To: Karl Denninger Cc: FreeBSD-STABLE Mailing List Subject: Re: 12.2 Splay Tree ipfw potential panic source Message-ID: <20210708221134.GA32658@belenus.iks-jena.de> References: <2e3dcd4d-c8e6-8381-0010-d0844c99901e@denninger.net> 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: <2e3dcd4d-c8e6-8381-0010-d0844c99901e@denninger.net> X-message-flag: Please send plain text messages only. Thank you. User-Agent: Mutt/1.5.17 (2007-11-01) X-Rspamd-Queue-Id: 4GLVrW5gTHz3LZK 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 Thu, Jul 08, 2021 at 05:38:35PM -0400, Karl Denninger wrote: > This is the only change I'm aware of in the build I just put on a firewall > that uses ipfw heavily, and it is not panic'ing quite regularly. The code was delayed considerably for MFC until such problems are identified, tested and solved (AFAIK) in main. The tests are also present in stable, and the CI system (jenkins) did not report any failure after MFCing. > I'll see if I can get a dump from it but that may be difficult as the > machine in question is a "small box" without attached storage (boots from > an SD card.) That would be really helpful. Most notably the bud I can't find easily are in the area of inbound redirection and protocol helpers. My use case is Carrier Grade NAT (outbound). From nobody Thu Jul 8 23:51:35 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 19B1811E6459; Thu, 8 Jul 2021 23:51:38 +0000 (UTC) (envelope-from lukasz@wasikowski.net) Received: from mail.freebsd.systems (mail.freebsd.systems [5.196.167.1]) (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 4GLY3Y6Xclz3s22; Thu, 8 Jul 2021 23:51:37 +0000 (UTC) (envelope-from lukasz@wasikowski.net) Received: from mail.freebsd.systems (mail.freebsd.systems [IPv6:2001:41d0:a:71bf::1]) by mail.freebsd.systems (Postfix) with ESMTP id 3EEFB1EBC2; Fri, 9 Jul 2021 01:51:36 +0200 (CEST) X-Virus-Scanned: amavisd-new at freebsd.systems Received: from mail.freebsd.systems ([IPv6:2001:41d0:a:71bf::1]) by mail.freebsd.systems (scan.freebsd.systems [IPv6:2001:41d0:a:71bf::1]) (amavisd-new, port 10026) with ESMTP id TXLaGeOM826E; Fri, 9 Jul 2021 01:51:36 +0200 (CEST) Received: from [192.168.168.3] (89-70-50-99.dynamic.chello.pl [89.70.50.99]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.freebsd.systems (Postfix) with ESMTPSA id AB6BC1EBC1; Fri, 9 Jul 2021 01:51:35 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wasikowski.net; s=default; t=1625788296; bh=/86pV7dxgYgslvMSAVy3Z7VjvsEDXIyFwULWLNU+Pqw=; h=To:Cc:References:From:Date:In-Reply-To; b=E02KQ7fyxxLE8sUSvz7ZMhDRNs5kgezRcyxRupuqN1AHv0rHm4ruKTLeMdqzByzX2 g7AiyLy68sL+xzH5SVhsZ5WXAaK2S8YRSeZVRaUIBAqvkgd86y/7p/SobNlCh2q0vo Nj3888JMMg44N+Dcf6WB0Axx4jR1z/Cbe0QFmY66XQMhRb4z34w8UGAy2alNnYey99 81o0A7jMhlZoIHVnVBvrTjpznGzGqg3IrYf10YMhjPTOhnYgwD3E/0Gj/wwDCT8HVF 0pQrdogvmpqlxZ3qr2ZWuQwswUhY4vLyTwIj0Q6+XYpYNt96lDwNkJKo8CUZtuBVvC 7v54beb7SNHpQ== Subject: Re: security/rkhunter without hashes after recent STABLE-13 update To: trashcan@ellael.org, Stefan Esser Cc: Warner Losh , FreeBSD-STABLE Mailing List , FreeBSD ports References: <416D3033-138D-4BBB-84FA-FAEA2944C837@ellael.org> <08637D0D-9D65-4F53-9A64-F4742BA8E415@ellael.org> <0B2C7AEA-27C6-4259-9DCF-D20C19737A50@ellael.org> <4355013a-0be1-829f-2fe5-86eeb4ba80f7@freebsd.org> From: =?UTF-8?Q?=c5=81ukasz_W=c4=85sikowski?= Message-ID: <6bd6fc12-f872-9560-81a0-5b9385fc85cd@wasikowski.net> Date: Fri, 9 Jul 2021 01:51:35 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 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 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: pl Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4GLY3Y6Xclz3s22 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N W dniu 2021-07-08 o 14:16, Michael Grimm via freebsd-stable pisze: > I can confirm that your patch works perfectly well. > No more workaround needed, now rkhunter calculates sha256 hashes as usual. > > Thanks for that. > > Now, Łukasz need's to confirm that rkhunter at 12.2-RELEASE will calculate those hashes as well. Works like a charm, thank you Stefan. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257065 -- Best regards, Łukasz Wąsikowski From nobody Fri Jul 9 00:53:01 2021 X-Original-To: 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 E1CEE124400F for ; Fri, 9 Jul 2021 00:53:03 +0000 (UTC) (envelope-from karl@denninger.net) Received: from colo1.denninger.net (colo1.denninger.net [104.236.120.189]) (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 4GLZQR1Zbtz4Vss for ; Fri, 9 Jul 2021 00:53:03 +0000 (UTC) (envelope-from karl@denninger.net) Received: from denninger.net (096-033-205-208.res.spectrum.com [96.33.205.208]) by colo1.denninger.net (Postfix) with ESMTP id 79D622110B2 for ; Thu, 8 Jul 2021 20:53:01 -0400 (EDT) Received: from [192.168.10.25] (D15.Denninger.Net [192.168.10.25]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by denninger.net (Postfix) with ESMTPSA id 0672B357B37 for ; Thu, 8 Jul 2021 20:53:02 -0400 (EDT) Subject: Re: 12.2 Splay Tree ipfw potential panic source To: stable@freebsd.org References: <2e3dcd4d-c8e6-8381-0010-d0844c99901e@denninger.net> <20210708221134.GA32658@belenus.iks-jena.de> From: Karl Denninger Message-ID: Date: Thu, 8 Jul 2021 20:53:01 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 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 In-Reply-To: <20210708221134.GA32658@belenus.iks-jena.de> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms070108030200080906010907" X-Rspamd-Queue-Id: 4GLZQR1Zbtz4Vss X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=denninger.net; spf=pass (mx1.freebsd.org: domain of karl@denninger.net designates 104.236.120.189 as permitted sender) smtp.mailfrom=karl@denninger.net X-Spamd-Result: default: False [-1.02 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+mx:c]; HAS_ATTACHMENT(0.00)[]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DMARC_POLICY_ALLOW(-0.50)[denninger.net,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:~]; RBL_DBL_DONT_QUERY_IPS(0.00)[104.236.120.189:from]; ASN(0.00)[asn:14061, ipnet:104.236.64.0/18, country:US]; R_DKIM_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[karl]; FROM_HAS_DN(0.00)[]; SIGNED_SMIME(-2.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_SHORT(0.49)[0.491]; MIME_GOOD(-0.20)[multipart/signed,multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[stable@freebsd.org]; NEURAL_SPAM_MEDIUM(0.45)[0.449]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[104.236.120.189:from:127.0.2.255]; RCVD_TLS_LAST(0.00)[]; NEURAL_SPAM_LONG(0.94)[0.937]; MAILMAN_DEST(0.00)[stable] X-ThisMailContainsUnwantedMimeParts: Y This is a cryptographically signed message in MIME format. --------------ms070108030200080906010907 Content-Type: multipart/alternative; boundary="------------6A2B34C73852BBF40B1EED06" Content-Language: en-US This is a multi-part message in MIME format. --------------6A2B34C73852BBF40B1EED06 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable On 7/8/2021 18:11, Lutz Donnerhacke wrote: > On Thu, Jul 08, 2021 at 05:38:35PM -0400, Karl Denninger wrote: >> This is the only change I'm aware of in the build I just put on a fire= wall >> that uses ipfw heavily, and it is not panic'ing quite regularly. > The code was delayed considerably for MFC until such problems are > identified, tested and solved (AFAIK) in main. The tests are also prese= nt in > stable, and the CI system (jenkins) did not report any failure after MF= Cing. > >> I'll see if I can get a dump from it but that may be difficult as the >> machine in question is a "small box" without attached storage (boots f= rom >> an SD card.) > That would be really helpful. Most notably the bud I can't find easily = are > in the area of inbound redirection and protocol helpers. My use case is= > Carrier Grade NAT (outbound). The box in question has a material number of "permanent" hole punch=20 redirects for inbound links, to wit: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ${fwcmd} nat 100 config if ${oif} l= og same_ports reset=20 redirect_port tcp=C2=A0 ${fwd}:2552 2552 redirect_port tcp=20 192.168.10.214:8080 8080 redirect_port tcp 192.168.10.203:443 4443=20 redirect_port tcp 192.168.10.216:8080 8088 redirect_port tcp ${fwd}:993 993 redirect_port tcp ${fwd}:4552 4552 redirect_port tcp=20 ${fwd}:imaps imaps redirect_port tcp ${fwd}:11443 11443 redirect_port=20 tcp ${fwd}:80 80 redirect_port tcp ${fwd}:2200 22042 The kernel with the splay-tree improvements survives less than /five=20 minutes /before it blows up -- repeatedly.=C2=A0 There is a client (on an= =20 Android phone) that maintains a connection via one of those=20 (specifically, to the 10.214 ip) along with inbound email on 2552 from=20 an off-site relay. I will see if I can get at least a panic backtrace, although the=20 impacted box is a pcEngines firewall that boots of an SD card.=C2=A0 An A= MD=20 box running the same rev but without any ipfw side of things running has = been up for a couple of days without incident.=C2=A0 Odds are reasonably-= high=20 the splay tree changes are responsible since that's the "stand-out"=20 difference between the two boxes. --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------6A2B34C73852BBF40B1EED06-- --------------ms070108030200080906010907 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC DdgwggagMIIEiKADAgECAhMA5EiKghDOXrvfxYxjITXYDdhIMA0GCSqGSIb3DQEBCwUAMIGL MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJTmljZXZpbGxlMRkw FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExITAf BgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQTAeFw0xNzA4MTcxNjQyMTdaFw0yNzA4 MTUxNjQyMTdaMHsxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkwFwYDVQQKDBBD dWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExJTAjBgNVBAMMHEN1 ZGEgU3lzdGVtcyBMTEMgMjAxNyBJbnQgQ0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQC1aJotNUI+W4jP7xQDO8L/b4XiF4Rss9O0B+3vMH7Njk85fZ052QhZpMVlpaaO+sCI KqG3oNEbuOHzJB/NDJFnqh7ijBwhdWutdsq23Ux6TvxgakyMPpT6TRNEJzcBVQA0kpby1DVD 0EKSK/FrWWBiFmSxg7qUfmIq/mMzgE6epHktyRM3OGq3dbRdOUgfumWrqHXOrdJz06xE9NzY vc9toqZnd79FUtE/nSZVm1VS3Grq7RKV65onvX3QOW4W1ldEHwggaZxgWGNiR/D4eosAGFxn uYeWlKEC70c99Mp1giWux+7ur6hc2E+AaTGh+fGeijO5q40OGd+dNMgK8Es0nDRw81lRcl24 SWUEky9y8DArgIFlRd6d3ZYwgc1DMTWkTavx3ZpASp5TWih6yI8ACwboTvlUYeooMsPtNa9E 6UQ1nt7VEi5syjxnDltbEFoLYcXBcqhRhFETJe9CdenItAHAtOya3w5+fmC2j/xJz29og1KH YqWHlo3Kswi9G77an+zh6nWkMuHs+03DU8DaOEWzZEav3lVD4u76bKRDTbhh0bMAk4eXriGL h4MUoX3Imfcr6JoyheVrAdHDL/BixbMH1UUspeRuqQMQ5b2T6pabXP0oOB4FqldWiDgJBGRd zWLgCYG8wPGJGYgHibl5rFiI5Ix3FQncipc6SdUzOQIDAQABo4IBCjCCAQYwHQYDVR0OBBYE FF3AXsKnjdPND5+bxVECGKtc047PMIHABgNVHSMEgbgwgbWAFBu1oRhUMNEzjODolDka5k4Q EDBioYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJ TmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5 c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYIJAKxAy1WBo2kY MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3DQEBCwUAA4IC AQCB5686UCBVIT52jO3sz9pKuhxuC2npi8ZvoBwt/IH9piPA15/CGF1XeXUdu2qmhOjHkVLN gO7XB1G8CuluxofOIUce0aZGyB+vZ1ylHXlMeB0R82f5dz3/T7RQso55Y2Vog2Zb7PYTC5B9 oNy3ylsnNLzanYlcW3AAfzZcbxYuAdnuq0Im3EpGm8DoItUcf1pDezugKm/yKtNtY6sDyENj tExZ377cYA3IdIwqn1Mh4OAT/Rmh8au2rZAo0+bMYBy9C11Ex0hQ8zWcvPZBDn4v4RtO8g+K uQZQcJnO09LJNtw94W3d2mj4a7XrsKMnZKvm6W9BJIQ4Nmht4wXAtPQ1xA+QpxPTmsGAU0Cv HmqVC7XC3qxFhaOrD2dsvOAK6Sn3MEpH/YrfYCX7a7cz5zW3DsJQ6o3pYfnnQz+hnwLlz4MK 17NIA0WOdAF9IbtQqarf44+PEyUbKtz1r0KGeGLs+VGdd2FLA0e7yuzxJDYcaBTVwqaHhU2/ Fna/jGU7BhrKHtJbb/XlLeFJ24yvuiYKpYWQSSyZu1R/gvZjHeGb344jGBsZdCDrdxtQQcVA 6OxsMAPSUPMrlg9LWELEEYnVulQJerWxpUecGH92O06wwmPgykkz//UmmgjVSh7ErNvL0lUY UMfunYVO/O5hwhW+P4gviCXzBFeTtDZH259O7TCCBzAwggUYoAMCAQICEwCg0WvVwekjGFiO 62SckFwepz0wDQYJKoZIhvcNAQELBQAwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3Jp ZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBD QTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExMQyAyMDE3IEludCBDQTAeFw0xNzA4MTcyMTIx MjBaFw0yMjA4MTYyMTIxMjBaMFcxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkw FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRswGQYDVQQDDBJrYXJsQGRlbm5pbmdlci5uZXQw ggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQC+HVSyxVtJhy3Ohs+PAGRuO//Dha9A 16l5FPATr6wude9zjX5f2lrkRyU8vhCXTZW7WbvWZKpcZ8r0dtZmiK9uF58Ec6hhvfkxJzbg 96WHBw5Fumd5ahZzuCJDtCAWW8R7/KN+zwzQf1+B3MVLmbaXAFBuKzySKhKMcHbK3/wjUYTg y+3UK6v2SBrowvkUBC+jxNg3Wy12GsTXcUS/8FYIXgVVPgfZZrbJJb5HWOQpvvhILpPCD3xs YJFNKEPltXKWHT7Qtc2HNqikgNwj8oqOb+PeZGMiWapsatKm8mxuOOGOEBhAoTVTwUHlMNTg 6QUCJtuWFCK38qOCyk9Haj+86lUU8RG6FkRXWgMbNQm1mWREQhw3axgGLSntjjnznJr5vsvX SYR6c+XKLd5KQZcS6LL8FHYNjqVKHBYM+hDnrTZMqa20JLAF1YagutDiMRURU23iWS7bA9tM cXcqkclTSDtFtxahRifXRI7Epq2GSKuEXe/1Tfb5CE8QsbCpGsfSwv2tZ/SpqVG08MdRiXxN 5tmZiQWo15IyWoeKOXl/hKxA9KPuDHngXX022b1ly+5ZOZbxBAZZMod4y4b4FiRUhRI97r9l CxsP/EPHuuTIZ82BYhrhbtab8HuRo2ofne2TfAWY2BlA7ExM8XShMd9bRPZrNTokPQPUCWCg CdIATQIDAQABo4IBzzCCAcswPAYIKwYBBQUHAQEEMDAuMCwGCCsGAQUFBzABhiBodHRwOi8v b2NzcC5jdWRhc3lzdGVtcy5uZXQ6ODg4ODAJBgNVHRMEAjAAMBEGCWCGSAGG+EIBAQQEAwIF oDAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMDMGCWCG SAGG+EIBDQQmFiRPcGVuU1NMIEdlbmVyYXRlZCBDbGllbnQgQ2VydGlmaWNhdGUwHQYDVR0O BBYEFLElmNWeVgsBPe7O8NiBzjvjYnpRMIHKBgNVHSMEgcIwgb+AFF3AXsKnjdPND5+bxVEC GKtc047PoYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UE BwwJTmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRh IFN5c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYITAORIioIQ zl6738WMYyE12A3YSDAdBgNVHREEFjAUgRJrYXJsQGRlbm5pbmdlci5uZXQwDQYJKoZIhvcN AQELBQADggIBAJXboPFBMLMtaiUt4KEtJCXlHO/3ZzIUIw/eobWFMdhe7M4+0u3te0sr77QR dcPKR0UeHffvpth2Mb3h28WfN0FmJmLwJk+pOx4u6uO3O0E1jNXoKh8fVcL4KU79oEQyYkbu 2HwbXBU9HbldPOOZDnPLi0whi/sbFHdyd4/w/NmnPgzAsQNZ2BYT9uBNr+jZw4SsluQzXG1X lFL/qCBoi1N2mqKPIepfGYF6drbr1RnXEJJsuD+NILLooTNf7PMgHPZ4VSWQXLNeFfygoOOK FiO0qfxPKpDMA+FHa8yNjAJZAgdJX5Mm1kbqipvb+r/H1UAmrzGMbhmf1gConsT5f8KU4n3Q IM2sOpTQe7BoVKlQM/fpQi6aBzu67M1iF1WtODpa5QUPvj1etaK+R3eYBzi4DIbCIWst8MdA 1+fEeKJFvMEZQONpkCwrJ+tJEuGQmjoQZgK1HeloepF0WDcviiho5FlgtAij+iBPtwMuuLiL shAXA5afMX1hYM4l11JXntle12EQFP1r6wOUkpOdxceCcMVDEJBBCHW2ZmdEaXgAm1VU+fnQ qS/wNw/S0X3RJT1qjr5uVlp2Y0auG/eG0jy6TT0KzTJeR9tLSDXprYkN2l/Qf7/nT6Q03qyE QnnKiBXWAZXveafyU/zYa7t3PTWFQGgWoC4w6XqgPo4KV44OMYIFBzCCBQMCAQEwgZIwezEL MAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBM TEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExM QyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTANBglghkgBZQMEAgMFAKCCAkUw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjEwNzA5MDA1MzAy WjBPBgkqhkiG9w0BCQQxQgRArCHP2kVXNJuVyuH/7HPLZnGreF8DOdiNAmTUyn/TGWw6JfGE 0kVbykOY7QAKmCSjdJUneULduZknbfhKv7yF5DBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFl AwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3 DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGjBgkrBgEEAYI3EAQxgZUwgZIwezEL MAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBM TEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExM QyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTCBpQYLKoZIhvcNAQkQAgsxgZWg gZIwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lz dGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0 ZW1zIExMQyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTANBgkqhkiG9w0BAQEF AASCAgAY+eUy64sS5m92Pe/uDujxUxOfG/hTXFZ/fJrAk9ITrS/nDh1iHngsKDdFdtTISCST flo388TW0K6IbK1o6SYfpgMh1Jq5uDJMMnra+jSBS6di2i8Fh4W0NNvc1E28WbZRapKOQa28 S2DHDC6J5S2/nYYYoPnz2e1mjzPjPdFIEdy99KHuPauxI6WBcrG5D9wmwqdVaykrTtybsEwx xM8xnKmD3L/FvjsVsiSVx3MmClvn8wp8mYVBE6HEfNS30i/qoEARVzzYLLBFZ1NCEikpL4XO 6D7JMbK1aUYbQqGeWkJEjW8fLrz2uE6wY2gQ7QOfL7nEyOwRBdeuK4P+mvVAiwBRNwG+mvzE mIa6eaXorEUbVlfvFSBVV6+NjtYDCfZGmU9uuxSc3R7X4cP42WW+fAkVQhk8VC6KlzDRiHY3 I5DRrkjFSVjuaQ0z71OdmlJxxZRlSD5BsIno/efIiyvBvggKdarjbo1/IL0RdRyT80GZN9S4 7OT+ICxCKpxVduFebcabW0FvOM05GaWUreDJm55stGGLeT1ffkQ4q4HyJDt4QQ35XsTkaGQF NN7iE4NoZ1Gec52f6sRa8HzWxchgfal3YvMsUSuHDy8SyvTSJGYVO/T7meB9WutSJV/4lq5N vIQkMuxXZl4b9nJYQz295MNRgkMcbML4ifSZSt7DzQAAAAAAAA== --------------ms070108030200080906010907-- From nobody Fri Jul 9 10:50:56 2021 X-Original-To: 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 4DF5B1273215 for ; Fri, 9 Jul 2021 10:51:05 +0000 (UTC) (envelope-from petefrench@ingresso.co.uk) Received: from constantine.ingresso.co.uk (constantine.ingresso.co.uk [IPv6:2001:470:6a18:411::3]) (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 4GLqhS27lyz4bnF for ; Fri, 9 Jul 2021 10:51:04 +0000 (UTC) (envelope-from petefrench@ingresso.co.uk) Received: from dilbert.ingresso.co.uk ([2001:470:6a18:411::6]) by constantine.ingresso.co.uk with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.94.2 (FreeBSD)) (envelope-from ) id 1m1o5x-0007xX-2m for stable@freebsd.org; Fri, 09 Jul 2021 10:50:57 +0000 Received: from petefrench by dilbert.ingresso.co.uk with local (Exim 4.94.2 (FreeBSD)) (envelope-from ) id 1m1o5w-000A3m-Rg for stable@freebsd.org; Fri, 09 Jul 2021 11:50:56 +0100 To: stable@freebsd.org Subject: Mysterious swap partition I can only get rid of on reboot Message-Id: From: Pete French Date: Fri, 09 Jul 2021 11:50:56 +0100 X-Rspamd-Queue-Id: 4GLqhS27lyz4bnF X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=ingresso.co.uk; spf=pass (mx1.freebsd.org: domain of petefrench@ingresso.co.uk designates 2001:470:6a18:411::3 as permitted sender) smtp.mailfrom=petefrench@ingresso.co.uk X-Spamd-Result: default: False [-3.79 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[2001:470:6a18:411::3:from]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2001:470:6a18:411::3]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.995]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[2001:470:6a18:411::3:from:127.0.2.255]; RCVD_COUNT_THREE(0.00)[3]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; DMARC_POLICY_ALLOW(-0.50)[ingresso.co.uk,none]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; MIME_TRACE(0.00)[0:+]; MAILMAN_DEST(0.00)[stable] X-ThisMailContainsUnwantedMimeParts: N 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 So, one thing which came out of my dying drives saga is this. I have a swap partition on each drive. on /dev/ada0p2 and /dev/ada1p2. When a drive dies, like ada0 did earlier, then swapinfo looks like this: Device 1K-blocks Used Avail Capacity /dev/#C:0x74 16777216 0 16777216 0% /dev/ada1p2 16777216 0 16777216 0% Total 33554432 0 33554432 0% OK, thats a bit odd. But I stick a new drive in, partition it, and run 'swapon -a' and it ends up looking like this: Device 1K-blocks Used Avail Capacity /dev/#C:0x74 16777216 0 16777216 0% /dev/ada0p2 16777216 0 16777216 0% /dev/ada1p2 16777216 0 16777216 0% Total 50331648 0 50331648 0% ...and the thing is that I cant remove /dev/#C:0x74 using swapoff that I have managed to find. I have to reboot to make it go away. -pete. From nobody Fri Jul 9 11:16:26 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 91E9E12760AF for ; Fri, 9 Jul 2021 11:16:30 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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 (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GLrFp3qyVz4fvQ; Fri, 9 Jul 2021 11:16:30 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from [192.168.0.88] (unknown [195.64.148.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: avg/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 15B4794CC; Fri, 9 Jul 2021 11:16:29 +0000 (UTC) (envelope-from avg@FreeBSD.org) Subject: Re: CPU hot-plug and RAM hot-add in virtual machines To: Miroslav Lachman <000.fbsd@quip.cz>, FreeBSD Stable Mailing List References: <4336a1bf-d826-dba3-9ec1-9b48cf7cd177@quip.cz> From: Andriy Gapon Message-ID: <70033628-bc3a-24d2-4c65-9a3b9c1c66d5@FreeBSD.org> Date: Fri, 9 Jul 2021 14:16:26 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Firefox/78.0 Thunderbird/78.11.0 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 In-Reply-To: <4336a1bf-d826-dba3-9ec1-9b48cf7cd177@quip.cz> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-ThisMailContainsUnwantedMimeParts: N On 08/07/2021 00:34, Miroslav Lachman wrote: > The question is simple but I cannot find answer - Does FreeBSD support hot-plug > vCPU and hot-add RAM? > Current virtualization platforms support adding CPU cores or additional RAM > without the need to reboot the guest OS. Some of our clients need to add > additional vCPUs or RAM so often that hot-plug and hot-add will be really > useful. If this is not supported on FreeBSD for now, is there any Work In > Progress? Or is there a plan to support it? I think that those features are not supported and I haven't heard of any WIP. -- Andriy Gapon From nobody Fri Jul 9 20:17:46 2021 X-Original-To: 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 4C79412740CA for ; Fri, 9 Jul 2021 20:17:59 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b]) (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 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GM4Gb1VClz3Frb for ; Fri, 9 Jul 2021 20:17:59 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: by mail-pj1-x102b.google.com with SMTP id g6-20020a17090adac6b029015d1a9a6f1aso7706105pjx.1 for ; Fri, 09 Jul 2021 13:17:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tEn3UvnPany/jud4msT74o4Lu0n3AB1LX2x/5RySbak=; b=CxVVQioA4ggi8nWZmQW7YqpCeQbJgui0kFWau7qItcdYwySFn5rOp4KmAW9GmBJawl hSZY95KQQeHOPjkr8/1j96Fd8XgJYjJXcVd+CollM6NiwkTUo9FvP1JvMF5kmwzHhLok TPpBnnOLdLDoh0M3yICGacz3vFqA09ByLEL3Yt5NPBdhqx1Gk9KZ3lwO5Xcm9DdN0fXU nPjLAVihHrxKJry2lYeKKwbh3+Lx+YJxIO7vFQEGahB0pIUlbA7SZKq2jPKayARPf/bk 9HPP1XU2T9QcN+FHT0Uru5g65s13OiVLJmd1O3d6SCECYtGOL24HkiqUI4rqHaPLCbjM B8Fg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tEn3UvnPany/jud4msT74o4Lu0n3AB1LX2x/5RySbak=; b=SQhFdhUh5caKAff+Z4+qjITPZ10EluBUWFRBZ/A96vYjRCCWN3x89DhQkA1TC7mFCg ZxZgI4PG/3aMLk+ZWgDrqhNIhwyKuAEIirlN6kamAPHaF1c3MOtuzlWETba98PeNG7te uthBsSPGdz62hvWG9dZbX2XaHLBCpeXrYnQj8Xl+Je6NKBxA8TQ8UKO3Ydi+t0QpUUto dtsZVxV5/lLwXAFW1WBikpx/gItw1sO3RoycleP+K8JTWrh5/UYhF04T1TbO+rcXAPah 61SF41k78APA0olFqg1sgaNJsW6/RkQNBLONiXSSyRVch1UdGb5r1Ke2tdewPPTP8+Ea C4hA== X-Gm-Message-State: AOAM530IjvxUnfcHHkp5bVbmjVk0tRPEgqMtxyeAT2E0/FCSMpmvg/Ml 4PjyDqfkC3BJxQlGylTyzeGP9VLUJAw052ZOK3yGhg1K X-Google-Smtp-Source: ABdhPJyTELwZ41bXD5/M+Gk31W+rhDneMcZC1CqC/H5IauQaV1MKLxT5PgCCHnIaijPG9s6CgUzml/7Gz8TLd4KjXDQ= X-Received: by 2002:a17:903:2482:b029:124:896b:6ac3 with SMTP id p2-20020a1709032482b0290124896b6ac3mr32008896plw.21.1625861877874; Fri, 09 Jul 2021 13:17:57 -0700 (PDT) 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 References: <2e3dcd4d-c8e6-8381-0010-d0844c99901e@denninger.net> <20210708221134.GA32658@belenus.iks-jena.de> In-Reply-To: From: Ryan Stone Date: Fri, 9 Jul 2021 16:17:46 -0400 Message-ID: Subject: Re: 12.2 Splay Tree ipfw potential panic source To: Karl Denninger Cc: stable@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4GM4Gb1VClz3Frb 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 Thu, Jul 8, 2021 at 8:54 PM Karl Denninger wrote: > I will see if I can get at least a panic backtrace, although the > impacted box is a pcEngines firewall that boots of an SD card. Have you checked whether netdump supports your NICs? You should be able to get a full vmcore off if so. From nobody Fri Jul 9 22:06:57 2021 X-Original-To: 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 9763111E137A for ; Fri, 9 Jul 2021 22:07:35 +0000 (UTC) (envelope-from karl@denninger.net) Received: from colo1.denninger.net (colo1.denninger.net [104.236.120.189]) (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 4GM6j25X7rz3jWg for ; Fri, 9 Jul 2021 22:07:34 +0000 (UTC) (envelope-from karl@denninger.net) Received: from denninger.net (096-033-205-208.res.spectrum.com [96.33.205.208]) by colo1.denninger.net (Postfix) with ESMTP id F23B32110D6 for ; Fri, 9 Jul 2021 18:06:56 -0400 (EDT) Received: from [192.168.10.25] (D15.Denninger.Net [192.168.10.25]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by denninger.net (Postfix) with ESMTPSA id 66EF236504F for ; Fri, 9 Jul 2021 18:06:57 -0400 (EDT) Subject: Re: 12.2 Splay Tree ipfw potential panic source To: stable@freebsd.org References: <2e3dcd4d-c8e6-8381-0010-d0844c99901e@denninger.net> <20210708221134.GA32658@belenus.iks-jena.de> From: Karl Denninger Message-ID: Date: Fri, 9 Jul 2021 18:06:57 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 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 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms050805040605070108060304" X-Rspamd-Queue-Id: 4GM6j25X7rz3jWg X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=denninger.net; spf=pass (mx1.freebsd.org: domain of karl@denninger.net designates 104.236.120.189 as permitted sender) smtp.mailfrom=karl@denninger.net X-Spamd-Result: default: False [-5.76 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; HAS_ATTACHMENT(0.00)[]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; NEURAL_HAM_SHORT(-0.86)[-0.862]; DMARC_POLICY_ALLOW(-0.50)[denninger.net,none]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[104.236.120.189:from]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:14061, ipnet:104.236.64.0/18, country:US]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEFALL_USER(0.00)[karl]; FROM_HAS_DN(0.00)[]; SIGNED_SMIME(-2.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,multipart/alternative,text/plain]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:~]; PREVIOUSLY_DELIVERED(0.00)[stable@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[104.236.120.189:from:127.0.2.255]; MAILMAN_DEST(0.00)[stable] X-ThisMailContainsUnwantedMimeParts: Y This is a cryptographically signed message in MIME format. --------------ms050805040605070108060304 Content-Type: multipart/alternative; boundary="------------617028FB232760B3D1E24A3B" Content-Language: en-US This is a multi-part message in MIME format. --------------617028FB232760B3D1E24A3B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable On 7/9/2021 16:17, Ryan Stone wrote: > On Thu, Jul 8, 2021 at 8:54 PM Karl Denninger wrot= e: >> I will see if I can get at least a panic backtrace, although the >> impacted box is a pcEngines firewall that boots of an SD card. > Have you checked whether netdump supports your NICs? You should be > able to get a full vmcore off if so. Yes; the box in question is in heavy production and I will not be able=20 to get an isolated period of time to pull a core (assuming the remote=20 dump works) until sometime this weekend. Will advise once I (hopefully) have it. --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------617028FB232760B3D1E24A3B-- --------------ms050805040605070108060304 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC DdgwggagMIIEiKADAgECAhMA5EiKghDOXrvfxYxjITXYDdhIMA0GCSqGSIb3DQEBCwUAMIGL MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJTmljZXZpbGxlMRkw FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExITAf BgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQTAeFw0xNzA4MTcxNjQyMTdaFw0yNzA4 MTUxNjQyMTdaMHsxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkwFwYDVQQKDBBD dWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExJTAjBgNVBAMMHEN1 ZGEgU3lzdGVtcyBMTEMgMjAxNyBJbnQgQ0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQC1aJotNUI+W4jP7xQDO8L/b4XiF4Rss9O0B+3vMH7Njk85fZ052QhZpMVlpaaO+sCI KqG3oNEbuOHzJB/NDJFnqh7ijBwhdWutdsq23Ux6TvxgakyMPpT6TRNEJzcBVQA0kpby1DVD 0EKSK/FrWWBiFmSxg7qUfmIq/mMzgE6epHktyRM3OGq3dbRdOUgfumWrqHXOrdJz06xE9NzY vc9toqZnd79FUtE/nSZVm1VS3Grq7RKV65onvX3QOW4W1ldEHwggaZxgWGNiR/D4eosAGFxn uYeWlKEC70c99Mp1giWux+7ur6hc2E+AaTGh+fGeijO5q40OGd+dNMgK8Es0nDRw81lRcl24 SWUEky9y8DArgIFlRd6d3ZYwgc1DMTWkTavx3ZpASp5TWih6yI8ACwboTvlUYeooMsPtNa9E 6UQ1nt7VEi5syjxnDltbEFoLYcXBcqhRhFETJe9CdenItAHAtOya3w5+fmC2j/xJz29og1KH YqWHlo3Kswi9G77an+zh6nWkMuHs+03DU8DaOEWzZEav3lVD4u76bKRDTbhh0bMAk4eXriGL h4MUoX3Imfcr6JoyheVrAdHDL/BixbMH1UUspeRuqQMQ5b2T6pabXP0oOB4FqldWiDgJBGRd zWLgCYG8wPGJGYgHibl5rFiI5Ix3FQncipc6SdUzOQIDAQABo4IBCjCCAQYwHQYDVR0OBBYE FF3AXsKnjdPND5+bxVECGKtc047PMIHABgNVHSMEgbgwgbWAFBu1oRhUMNEzjODolDka5k4Q EDBioYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJ TmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5 c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYIJAKxAy1WBo2kY MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3DQEBCwUAA4IC AQCB5686UCBVIT52jO3sz9pKuhxuC2npi8ZvoBwt/IH9piPA15/CGF1XeXUdu2qmhOjHkVLN gO7XB1G8CuluxofOIUce0aZGyB+vZ1ylHXlMeB0R82f5dz3/T7RQso55Y2Vog2Zb7PYTC5B9 oNy3ylsnNLzanYlcW3AAfzZcbxYuAdnuq0Im3EpGm8DoItUcf1pDezugKm/yKtNtY6sDyENj tExZ377cYA3IdIwqn1Mh4OAT/Rmh8au2rZAo0+bMYBy9C11Ex0hQ8zWcvPZBDn4v4RtO8g+K uQZQcJnO09LJNtw94W3d2mj4a7XrsKMnZKvm6W9BJIQ4Nmht4wXAtPQ1xA+QpxPTmsGAU0Cv HmqVC7XC3qxFhaOrD2dsvOAK6Sn3MEpH/YrfYCX7a7cz5zW3DsJQ6o3pYfnnQz+hnwLlz4MK 17NIA0WOdAF9IbtQqarf44+PEyUbKtz1r0KGeGLs+VGdd2FLA0e7yuzxJDYcaBTVwqaHhU2/ Fna/jGU7BhrKHtJbb/XlLeFJ24yvuiYKpYWQSSyZu1R/gvZjHeGb344jGBsZdCDrdxtQQcVA 6OxsMAPSUPMrlg9LWELEEYnVulQJerWxpUecGH92O06wwmPgykkz//UmmgjVSh7ErNvL0lUY UMfunYVO/O5hwhW+P4gviCXzBFeTtDZH259O7TCCBzAwggUYoAMCAQICEwCg0WvVwekjGFiO 62SckFwepz0wDQYJKoZIhvcNAQELBQAwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3Jp ZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBD QTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExMQyAyMDE3IEludCBDQTAeFw0xNzA4MTcyMTIx MjBaFw0yMjA4MTYyMTIxMjBaMFcxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkw FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRswGQYDVQQDDBJrYXJsQGRlbm5pbmdlci5uZXQw ggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQC+HVSyxVtJhy3Ohs+PAGRuO//Dha9A 16l5FPATr6wude9zjX5f2lrkRyU8vhCXTZW7WbvWZKpcZ8r0dtZmiK9uF58Ec6hhvfkxJzbg 96WHBw5Fumd5ahZzuCJDtCAWW8R7/KN+zwzQf1+B3MVLmbaXAFBuKzySKhKMcHbK3/wjUYTg y+3UK6v2SBrowvkUBC+jxNg3Wy12GsTXcUS/8FYIXgVVPgfZZrbJJb5HWOQpvvhILpPCD3xs YJFNKEPltXKWHT7Qtc2HNqikgNwj8oqOb+PeZGMiWapsatKm8mxuOOGOEBhAoTVTwUHlMNTg 6QUCJtuWFCK38qOCyk9Haj+86lUU8RG6FkRXWgMbNQm1mWREQhw3axgGLSntjjnznJr5vsvX SYR6c+XKLd5KQZcS6LL8FHYNjqVKHBYM+hDnrTZMqa20JLAF1YagutDiMRURU23iWS7bA9tM cXcqkclTSDtFtxahRifXRI7Epq2GSKuEXe/1Tfb5CE8QsbCpGsfSwv2tZ/SpqVG08MdRiXxN 5tmZiQWo15IyWoeKOXl/hKxA9KPuDHngXX022b1ly+5ZOZbxBAZZMod4y4b4FiRUhRI97r9l CxsP/EPHuuTIZ82BYhrhbtab8HuRo2ofne2TfAWY2BlA7ExM8XShMd9bRPZrNTokPQPUCWCg CdIATQIDAQABo4IBzzCCAcswPAYIKwYBBQUHAQEEMDAuMCwGCCsGAQUFBzABhiBodHRwOi8v b2NzcC5jdWRhc3lzdGVtcy5uZXQ6ODg4ODAJBgNVHRMEAjAAMBEGCWCGSAGG+EIBAQQEAwIF oDAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMDMGCWCG SAGG+EIBDQQmFiRPcGVuU1NMIEdlbmVyYXRlZCBDbGllbnQgQ2VydGlmaWNhdGUwHQYDVR0O BBYEFLElmNWeVgsBPe7O8NiBzjvjYnpRMIHKBgNVHSMEgcIwgb+AFF3AXsKnjdPND5+bxVEC GKtc047PoYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UE BwwJTmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRh IFN5c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYITAORIioIQ zl6738WMYyE12A3YSDAdBgNVHREEFjAUgRJrYXJsQGRlbm5pbmdlci5uZXQwDQYJKoZIhvcN AQELBQADggIBAJXboPFBMLMtaiUt4KEtJCXlHO/3ZzIUIw/eobWFMdhe7M4+0u3te0sr77QR dcPKR0UeHffvpth2Mb3h28WfN0FmJmLwJk+pOx4u6uO3O0E1jNXoKh8fVcL4KU79oEQyYkbu 2HwbXBU9HbldPOOZDnPLi0whi/sbFHdyd4/w/NmnPgzAsQNZ2BYT9uBNr+jZw4SsluQzXG1X lFL/qCBoi1N2mqKPIepfGYF6drbr1RnXEJJsuD+NILLooTNf7PMgHPZ4VSWQXLNeFfygoOOK FiO0qfxPKpDMA+FHa8yNjAJZAgdJX5Mm1kbqipvb+r/H1UAmrzGMbhmf1gConsT5f8KU4n3Q IM2sOpTQe7BoVKlQM/fpQi6aBzu67M1iF1WtODpa5QUPvj1etaK+R3eYBzi4DIbCIWst8MdA 1+fEeKJFvMEZQONpkCwrJ+tJEuGQmjoQZgK1HeloepF0WDcviiho5FlgtAij+iBPtwMuuLiL shAXA5afMX1hYM4l11JXntle12EQFP1r6wOUkpOdxceCcMVDEJBBCHW2ZmdEaXgAm1VU+fnQ qS/wNw/S0X3RJT1qjr5uVlp2Y0auG/eG0jy6TT0KzTJeR9tLSDXprYkN2l/Qf7/nT6Q03qyE QnnKiBXWAZXveafyU/zYa7t3PTWFQGgWoC4w6XqgPo4KV44OMYIFBzCCBQMCAQEwgZIwezEL MAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBM TEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExM QyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTANBglghkgBZQMEAgMFAKCCAkUw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjEwNzA5MjIwNjU3 WjBPBgkqhkiG9w0BCQQxQgRAE7fhLfT9tfyAwJim9SaQy+s4vmC+bRnIc6p4fx40h1YRCLzF kjAvOjETz0m6XcWkxRY3TjFaNhrQa0dkH4mxmDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFl AwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3 DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGjBgkrBgEEAYI3EAQxgZUwgZIwezEL MAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBM TEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExM QyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTCBpQYLKoZIhvcNAQkQAgsxgZWg gZIwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lz dGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0 ZW1zIExMQyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTANBgkqhkiG9w0BAQEF AASCAgApvOijJCst7Ck/B4BCqgAixZfxY2Ege1Ro9gqNQvgJU65IaGInrDsAlqs7IqNMmQDy A8YhVcd/M+OXSf4yI+vJODk6jd0tM8S0aHD4fvDhYvAOtY8MUujESGP9tgL0sBmdIwo87gtl 69qByQcCkzKCV9IGQ/T/GRmHMVhW4XiXu/qphU/y7vwMViZ5vKWUoo2C0aodbkbMQit+NMW4 F43pS+2Z78FrbW9rSiSAsB3ODLIJLWK9Vz8s43uoydSfSQD9C37dBcc5woh6fpPiiY9rwAWA Iy5qAygaJUWJxvUVwdSH0ihmn4FhnM8JpnSM87dNeLfOwruMbqGl91s9xxOpiinaoypdabvS jCKm6selog/RMpzltMknqIngvrfaJMo626YEiFdrsZh7YZnlXs8K3/ak+80sPY1yljSEqHzK Zt3q3NLILIOYyO05MCRDqWihA/xhQeLI3vp/JGID+JCmYOH41MReyP4CMSpPCBKVVSGQhFIm dTP5IAWOjNJO8WiV+yXkJRaGtdY68c6uS5U7Eqlo9dceD9d8GFP4dmA9SU5Mo/ms3QKuzTah wVnUzSb89YkthA7eDXQrRIj4anLsgacVIfh1R/X9TY5Czd4UVNcSCjCJJa6hl6GgSsH8SEXp KmXIWNrVkEPy9S6Ixbh2xpO7jfVMik1RVMzHQZApOAAAAAAAAA== --------------ms050805040605070108060304-- From nobody Sat Jul 10 02:41:00 2021 X-Original-To: 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 27F0E11CC2AD for ; Sat, 10 Jul 2021 02:41:04 +0000 (UTC) (envelope-from karl@denninger.net) Received: from colo1.denninger.net (colo1.denninger.net [104.236.120.189]) (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 4GMDmb0qGhz4mCM for ; Sat, 10 Jul 2021 02:41:02 +0000 (UTC) (envelope-from karl@denninger.net) Received: from denninger.net (096-033-205-208.res.spectrum.com [96.33.205.208]) by colo1.denninger.net (Postfix) with ESMTP id D4EE12110C3 for ; Fri, 9 Jul 2021 22:41:00 -0400 (EDT) Received: from [192.168.10.25] (D15.Denninger.Net [192.168.10.25]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by denninger.net (Postfix) with ESMTPSA id A0DCF365F42 for ; Fri, 9 Jul 2021 22:40:59 -0400 (EDT) Subject: Re: 12.2 Splay Tree ipfw potential panic source To: stable@freebsd.org References: <2e3dcd4d-c8e6-8381-0010-d0844c99901e@denninger.net> <20210708221134.GA32658@belenus.iks-jena.de> From: Karl Denninger Message-ID: <7bfda38b-cf81-d8be-7691-e18946e6b56e@denninger.net> Date: Fri, 9 Jul 2021 22:41:00 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 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 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms060608010600000502000206" X-Rspamd-Queue-Id: 4GMDmb0qGhz4mCM X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=denninger.net; spf=pass (mx1.freebsd.org: domain of karl@denninger.net designates 104.236.120.189 as permitted sender) smtp.mailfrom=karl@denninger.net X-Spamd-Result: default: False [-5.90 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; HAS_ATTACHMENT(0.00)[]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[denninger.net,none]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[104.236.120.189:from]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:14061, ipnet:104.236.64.0/18, country:US]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEFALL_USER(0.00)[karl]; FROM_HAS_DN(0.00)[]; SIGNED_SMIME(-2.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,multipart/alternative,text/plain]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:~]; PREVIOUSLY_DELIVERED(0.00)[stable@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[104.236.120.189:from:127.0.2.255]; MAILMAN_DEST(0.00)[stable] X-ThisMailContainsUnwantedMimeParts: Y This is a cryptographically signed message in MIME format. --------------ms060608010600000502000206 Content-Type: multipart/alternative; boundary="------------4FA32C454518EECB922BCACF" Content-Language: en-US This is a multi-part message in MIME format. --------------4FA32C454518EECB922BCACF Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable On 7/9/2021 18:06, Karl Denninger wrote: > On 7/9/2021 16:17, Ryan Stone wrote: >> On Thu, Jul 8, 2021 at 8:54 PM Karl Denninger =20 >> wrote: >>> I will see if I can get at least a panic backtrace, although the >>> impacted box is a pcEngines firewall that boots of an SD card. >> Have you checked whether netdump supports your NICs?=C2=A0 You should = be >> able to get a full vmcore off if so. > > Yes; the box in question is in heavy production and I will not be able = > to get an isolated period of time to pull a core (assuming the remote=20 > dump works) until sometime this weekend. > > Will advise once I (hopefully) have it. > Ok, so I have good news and bad news. I have the trap and it is definitely in libalias which appears to come=20 about as a result of a NAT translation attempt. Fatal trap 18: integer divide fault while in kernel mode cpuid =3D 1; apic id =3D 01 instruction pointer=C2=A0=C2=A0=C2=A0=C2=A0 =3D 0x20:0xffffffff8275b7cc stack pointer=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =3D 0x28:0xfffffe0017b6b310 frame pointer=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =3D 0x28:0xfffffe0017b6b320 code segment=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 =3D base 0x0, limit 0xfffff, type 0x1b =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D DP= L 0, pres 1, long 1, def32 0, gran 1 processor eflags=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D interrupt = enabled, resume, IOPL =3D 0 current process=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D 0 (if= _io_tqg_1) trap number=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 =3D 18 panic: integer divide fault cpuid =3D 1 time =3D 1625883072 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame=20 0xfffffe0017b6b020 vpanic() at vpanic+0x17b/frame 0xfffffe0017b6b070 panic() at panic+0x43/frame 0xfffffe0017b6b0d0 trap_fatal() at trap_fatal+0x391/frame 0xfffffe0017b6b130 trap() at trap+0x67/frame 0xfffffe0017b6b240 calltrap() at calltrap+0x8/frame 0xfffffe0017b6b240 --- trap 0x12, rip =3D 0xffffffff8275b7cc, rsp =3D 0xfffffe0017b6b310, rb= p =3D=20 0xfffffe0017b6b320 --- HouseKeeping() at HouseKeeping+0x1c/frame 0xfffffe0017b6b320 LibAliasInLocked() at LibAliasInLocked+0x2f/frame 0xfffffe0017b6b3e0 LibAliasIn() at LibAliasIn+0x46/frame 0xfffffe0017b6b410 ipfw_nat() at ipfw_nat+0x234/frame 0xfffffe0017b6b460 ipfw_chk() at ipfw_chk+0x1350/frame 0xfffffe0017b6b670 ipfw_check_packet() at ipfw_check_packet+0xf0/frame 0xfffffe0017b6b760 pfil_run_hooks() at pfil_run_hooks+0xb0/frame 0xfffffe0017b6b7f0 ip_input() at ip_input+0x427/frame 0xfffffe0017b6b8a0 netisr_dispatch_src() at netisr_dispatch_src+0xca/frame 0xfffffe0017b6b8f= 0 ether_demux() at ether_demux+0x138/frame 0xfffffe0017b6b920 ether_nh_input() at ether_nh_input+0x33b/frame 0xfffffe0017b6b980 netisr_dispatch_src() at netisr_dispatch_src+0xca/frame 0xfffffe0017b6b9d= 0 ether_input() at ether_input+0x4b/frame 0xfffffe0017b6ba00 iflib_rxeof() at iflib_rxeof+0xad6/frame 0xfffffe0017b6bae0 _task_fn_rx() at _task_fn_rx+0x72/frame 0xfffffe0017b6bb20 gtaskqueue_run_locked() at gtaskqueue_run_locked+0x121/frame=20 0xfffffe0017b6bb80 gtaskqueue_thread_loop() at gtaskqueue_thread_loop+0xb6/frame=20 0xfffffe0017b6bbb0 fork_exit() at fork_exit+0x7e/frame 0xfffffe0017b6bbf0 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe0017b6bbf0 --- trap 0, rip =3D 0, rsp =3D 0, rbp =3D 0 --- Uptime: 7m23s netdump: overwriting mbuf zone pointers netdump in progress. searching for server... netdumping to 192.168.10.100 (ac:1f:6b:ad:d8:cb) Dumping 190 out of 1882 MB:. . . . . . . . . . . . . ** DUMP FAILED (ERROR 60) ** Now the bad news -- as you can see, an attempted remote dump fails,=20 possibly because the network code at that point is hosed. I get a 69632=20 length file (exactly and repeatedly) on the remote machine where the=20 dump is set to go; it looks like the first piece of it is indeed=20 received but that's it and then the panic'd unit reboots. On the server (remote) end I have this in the "info" file: Dump from IpGw [192.168.10.200] Dump incomplete: client timed out So it looks like it got the first part of it, the server replied but the = crashed box never sent anything else. -rw-------=C2=A0=C2=A0 1 root=C2=A0 wheel=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2= Jul=C2=A0 9 22:11 bounds.IpGw -rw-------=C2=A0=C2=A0 1 root=C2=A0 wheel=C2=A0=C2=A0=C2=A0=C2=A0 66 Jul=C2= =A0 9 22:10 info.IpGw.0 -rw-------=C2=A0=C2=A0 1 root=C2=A0 wheel=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 0= Jul=C2=A0 9 22:11 info.IpGw.1 -rw-------=C2=A0=C2=A0 1 root=C2=A0 wheel=C2=A0 69632 Jul=C2=A0 9 22:00 v= mcore.IpGw.0 -rw-------=C2=A0=C2=A0 1 root=C2=A0 wheel=C2=A0 69632 Jul=C2=A0 9 22:11 v= mcore.IpGw.1 Without a complete core I can't give you a good traceback.=C2=A0 I may be= =20 able to get a local device on this unit sometime over the weekend=20 sometime -- not sure as of yet as it is in production use. This is an extremely reliable panic -- uptime is only a few minutes=20 before it blows up. --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------4FA32C454518EECB922BCACF-- --------------ms060608010600000502000206 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC DdgwggagMIIEiKADAgECAhMA5EiKghDOXrvfxYxjITXYDdhIMA0GCSqGSIb3DQEBCwUAMIGL MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJTmljZXZpbGxlMRkw FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExITAf BgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQTAeFw0xNzA4MTcxNjQyMTdaFw0yNzA4 MTUxNjQyMTdaMHsxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkwFwYDVQQKDBBD dWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExJTAjBgNVBAMMHEN1 ZGEgU3lzdGVtcyBMTEMgMjAxNyBJbnQgQ0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQC1aJotNUI+W4jP7xQDO8L/b4XiF4Rss9O0B+3vMH7Njk85fZ052QhZpMVlpaaO+sCI KqG3oNEbuOHzJB/NDJFnqh7ijBwhdWutdsq23Ux6TvxgakyMPpT6TRNEJzcBVQA0kpby1DVD 0EKSK/FrWWBiFmSxg7qUfmIq/mMzgE6epHktyRM3OGq3dbRdOUgfumWrqHXOrdJz06xE9NzY vc9toqZnd79FUtE/nSZVm1VS3Grq7RKV65onvX3QOW4W1ldEHwggaZxgWGNiR/D4eosAGFxn uYeWlKEC70c99Mp1giWux+7ur6hc2E+AaTGh+fGeijO5q40OGd+dNMgK8Es0nDRw81lRcl24 SWUEky9y8DArgIFlRd6d3ZYwgc1DMTWkTavx3ZpASp5TWih6yI8ACwboTvlUYeooMsPtNa9E 6UQ1nt7VEi5syjxnDltbEFoLYcXBcqhRhFETJe9CdenItAHAtOya3w5+fmC2j/xJz29og1KH YqWHlo3Kswi9G77an+zh6nWkMuHs+03DU8DaOEWzZEav3lVD4u76bKRDTbhh0bMAk4eXriGL h4MUoX3Imfcr6JoyheVrAdHDL/BixbMH1UUspeRuqQMQ5b2T6pabXP0oOB4FqldWiDgJBGRd zWLgCYG8wPGJGYgHibl5rFiI5Ix3FQncipc6SdUzOQIDAQABo4IBCjCCAQYwHQYDVR0OBBYE FF3AXsKnjdPND5+bxVECGKtc047PMIHABgNVHSMEgbgwgbWAFBu1oRhUMNEzjODolDka5k4Q EDBioYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJ TmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5 c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYIJAKxAy1WBo2kY MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3DQEBCwUAA4IC AQCB5686UCBVIT52jO3sz9pKuhxuC2npi8ZvoBwt/IH9piPA15/CGF1XeXUdu2qmhOjHkVLN gO7XB1G8CuluxofOIUce0aZGyB+vZ1ylHXlMeB0R82f5dz3/T7RQso55Y2Vog2Zb7PYTC5B9 oNy3ylsnNLzanYlcW3AAfzZcbxYuAdnuq0Im3EpGm8DoItUcf1pDezugKm/yKtNtY6sDyENj tExZ377cYA3IdIwqn1Mh4OAT/Rmh8au2rZAo0+bMYBy9C11Ex0hQ8zWcvPZBDn4v4RtO8g+K uQZQcJnO09LJNtw94W3d2mj4a7XrsKMnZKvm6W9BJIQ4Nmht4wXAtPQ1xA+QpxPTmsGAU0Cv HmqVC7XC3qxFhaOrD2dsvOAK6Sn3MEpH/YrfYCX7a7cz5zW3DsJQ6o3pYfnnQz+hnwLlz4MK 17NIA0WOdAF9IbtQqarf44+PEyUbKtz1r0KGeGLs+VGdd2FLA0e7yuzxJDYcaBTVwqaHhU2/ Fna/jGU7BhrKHtJbb/XlLeFJ24yvuiYKpYWQSSyZu1R/gvZjHeGb344jGBsZdCDrdxtQQcVA 6OxsMAPSUPMrlg9LWELEEYnVulQJerWxpUecGH92O06wwmPgykkz//UmmgjVSh7ErNvL0lUY UMfunYVO/O5hwhW+P4gviCXzBFeTtDZH259O7TCCBzAwggUYoAMCAQICEwCg0WvVwekjGFiO 62SckFwepz0wDQYJKoZIhvcNAQELBQAwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3Jp ZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBD QTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExMQyAyMDE3IEludCBDQTAeFw0xNzA4MTcyMTIx MjBaFw0yMjA4MTYyMTIxMjBaMFcxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkw FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRswGQYDVQQDDBJrYXJsQGRlbm5pbmdlci5uZXQw ggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQC+HVSyxVtJhy3Ohs+PAGRuO//Dha9A 16l5FPATr6wude9zjX5f2lrkRyU8vhCXTZW7WbvWZKpcZ8r0dtZmiK9uF58Ec6hhvfkxJzbg 96WHBw5Fumd5ahZzuCJDtCAWW8R7/KN+zwzQf1+B3MVLmbaXAFBuKzySKhKMcHbK3/wjUYTg y+3UK6v2SBrowvkUBC+jxNg3Wy12GsTXcUS/8FYIXgVVPgfZZrbJJb5HWOQpvvhILpPCD3xs YJFNKEPltXKWHT7Qtc2HNqikgNwj8oqOb+PeZGMiWapsatKm8mxuOOGOEBhAoTVTwUHlMNTg 6QUCJtuWFCK38qOCyk9Haj+86lUU8RG6FkRXWgMbNQm1mWREQhw3axgGLSntjjnznJr5vsvX SYR6c+XKLd5KQZcS6LL8FHYNjqVKHBYM+hDnrTZMqa20JLAF1YagutDiMRURU23iWS7bA9tM cXcqkclTSDtFtxahRifXRI7Epq2GSKuEXe/1Tfb5CE8QsbCpGsfSwv2tZ/SpqVG08MdRiXxN 5tmZiQWo15IyWoeKOXl/hKxA9KPuDHngXX022b1ly+5ZOZbxBAZZMod4y4b4FiRUhRI97r9l CxsP/EPHuuTIZ82BYhrhbtab8HuRo2ofne2TfAWY2BlA7ExM8XShMd9bRPZrNTokPQPUCWCg CdIATQIDAQABo4IBzzCCAcswPAYIKwYBBQUHAQEEMDAuMCwGCCsGAQUFBzABhiBodHRwOi8v b2NzcC5jdWRhc3lzdGVtcy5uZXQ6ODg4ODAJBgNVHRMEAjAAMBEGCWCGSAGG+EIBAQQEAwIF oDAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMDMGCWCG SAGG+EIBDQQmFiRPcGVuU1NMIEdlbmVyYXRlZCBDbGllbnQgQ2VydGlmaWNhdGUwHQYDVR0O BBYEFLElmNWeVgsBPe7O8NiBzjvjYnpRMIHKBgNVHSMEgcIwgb+AFF3AXsKnjdPND5+bxVEC GKtc047PoYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UE BwwJTmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRh IFN5c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYITAORIioIQ zl6738WMYyE12A3YSDAdBgNVHREEFjAUgRJrYXJsQGRlbm5pbmdlci5uZXQwDQYJKoZIhvcN AQELBQADggIBAJXboPFBMLMtaiUt4KEtJCXlHO/3ZzIUIw/eobWFMdhe7M4+0u3te0sr77QR dcPKR0UeHffvpth2Mb3h28WfN0FmJmLwJk+pOx4u6uO3O0E1jNXoKh8fVcL4KU79oEQyYkbu 2HwbXBU9HbldPOOZDnPLi0whi/sbFHdyd4/w/NmnPgzAsQNZ2BYT9uBNr+jZw4SsluQzXG1X lFL/qCBoi1N2mqKPIepfGYF6drbr1RnXEJJsuD+NILLooTNf7PMgHPZ4VSWQXLNeFfygoOOK FiO0qfxPKpDMA+FHa8yNjAJZAgdJX5Mm1kbqipvb+r/H1UAmrzGMbhmf1gConsT5f8KU4n3Q IM2sOpTQe7BoVKlQM/fpQi6aBzu67M1iF1WtODpa5QUPvj1etaK+R3eYBzi4DIbCIWst8MdA 1+fEeKJFvMEZQONpkCwrJ+tJEuGQmjoQZgK1HeloepF0WDcviiho5FlgtAij+iBPtwMuuLiL shAXA5afMX1hYM4l11JXntle12EQFP1r6wOUkpOdxceCcMVDEJBBCHW2ZmdEaXgAm1VU+fnQ qS/wNw/S0X3RJT1qjr5uVlp2Y0auG/eG0jy6TT0KzTJeR9tLSDXprYkN2l/Qf7/nT6Q03qyE QnnKiBXWAZXveafyU/zYa7t3PTWFQGgWoC4w6XqgPo4KV44OMYIFBzCCBQMCAQEwgZIwezEL MAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBM TEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExM QyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTANBglghkgBZQMEAgMFAKCCAkUw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjEwNzEwMDI0MTAw WjBPBgkqhkiG9w0BCQQxQgRAP3Klgmpa1kctKVqfx0bF5eclItSpkCmzQxzVTlpg2PJWlPEJ eZH3YzQPSBuIVYBZA+rn5Qya0RSg+sfRT5RMzzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFl AwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3 DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGjBgkrBgEEAYI3EAQxgZUwgZIwezEL MAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBM TEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExM QyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTCBpQYLKoZIhvcNAQkQAgsxgZWg gZIwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lz dGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0 ZW1zIExMQyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTANBgkqhkiG9w0BAQEF AASCAgBxBKyMqAhZqnrr836e9z28E7bm2V3Im3h/ZneaxFDmqk/MvU6MvVcjOuRgKmo8SUTn IvPUGdP5FkgpVxJkXN8lvabooiEh95C6y6BcDgcI7r9QhCP9OCdi++7l4vBcE3qWYKkI7EEK dM8i4LKgMo4UYDKEZO+sh6Redx9AyUPtNJmReKOPE1CylgtgF7hAKnwFQhO7UG2PZdNzOvrZ big5THGKU5aBTZ2zFdH8HHmWG7DT/I+oqXndtx5chIZg2M3wvWyQoL9jHsGOR1OMUr0QB4w5 /iZMWbn2ve48CMmUbDRM8BuK0w5M3Um1vvcraezSqaohP6WZs7xa0YUdv4HkJuy0ukoBRJZn wF1F/ZY5sejR653p4+CkYZE4QjVBAxHqQkysHhFM9TjRLsJ8rts4WuwX553op/loW/cVdGAT gs0P7H1IihV3apP2LvIxMNwcSXhRXQNuQHfZ+7hZgI/iCfJqNQs0ufn9U94NSJCFJ6Of4wlk CPtd6aG2aV2oLvpya5rSuu8f38NY/2MH8hqlUpForpSlj37UqCG6mlunuF9az9gGZnmI6cVe ef3h61Ow5uoguNQ31fap1mChGMxKvCwUHDDc8/9ztUK+Q88ZJZlrd2xo0h+QPi2qe22giW7J jjLzwkoDP5Z81FjftQAOvF7IwTFeOfuc92BMff1OMwAAAAAAAA== --------------ms060608010600000502000206-- From nobody Sat Jul 10 08:23:04 2021 X-Original-To: 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 6FE75CFAE87 for ; Sat, 10 Jul 2021 08:23:08 +0000 (UTC) (envelope-from se@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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 (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GMNMJ2YHkz3rhR; Sat, 10 Jul 2021 08:23:08 +0000 (UTC) (envelope-from se@freebsd.org) Received: from Stefans-MBP-449.fritz.box (p200300cd5f098700843d0a051b030d69.dip0.t-ipconnect.de [IPv6:2003:cd:5f09:8700:843d:a05:1b03:d69]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: se/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id C12C52490B; Sat, 10 Jul 2021 08:23:07 +0000 (UTC) (envelope-from se@freebsd.org) To: Karl Denninger , stable@freebsd.org References: <2e3dcd4d-c8e6-8381-0010-d0844c99901e@denninger.net> <20210708221134.GA32658@belenus.iks-jena.de> <7bfda38b-cf81-d8be-7691-e18946e6b56e@denninger.net> From: Stefan Esser Subject: Re: 12.2 Splay Tree ipfw potential panic source Message-ID: Date: Sat, 10 Jul 2021 10:23:04 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 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 In-Reply-To: <7bfda38b-cf81-d8be-7691-e18946e6b56e@denninger.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="W1eXtNstIDZ7j46JgX9A1af8FiCTdxjuL" X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --W1eXtNstIDZ7j46JgX9A1af8FiCTdxjuL Content-Type: multipart/mixed; boundary="AfG0Ry9dlrnkfcr2T0uWIqA9mHH9XwLIE"; protected-headers="v1" From: Stefan Esser To: Karl Denninger , stable@freebsd.org Message-ID: Subject: Re: 12.2 Splay Tree ipfw potential panic source References: <2e3dcd4d-c8e6-8381-0010-d0844c99901e@denninger.net> <20210708221134.GA32658@belenus.iks-jena.de> <7bfda38b-cf81-d8be-7691-e18946e6b56e@denninger.net> In-Reply-To: <7bfda38b-cf81-d8be-7691-e18946e6b56e@denninger.net> --AfG0Ry9dlrnkfcr2T0uWIqA9mHH9XwLIE Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Am 10.07.21 um 04:41 schrieb Karl Denninger: > Ok, so I have good news and bad news. >=20 > I have the trap and it is definitely in libalias which appears to come = about as > a result of a NAT translation attempt. >=20 > Fatal trap 18: integer divide fault while in kernel mode [...] > HouseKeeping() at HouseKeeping+0x1c/frame 0xfffffe0017b6b320 The divide by zero at one of the first instructions of HouseKeeping() seems to be caused by this line: /sys/netinet/libalias/alias_db.c:1753: if (packets % packet_limit =3D=3D 0) { Seems that packet_limit can become zero, there ... At line 1780 within that function: if (now !=3D LibAliasTime) { /* retry three times a second */ packet_limit =3D packets / 3; packets =3D 0; LibAliasTime =3D now; } The static variable packet limit is divided by 3 without any protection against going down to 0. A packet_limit of zero makes no sense (besides causing a divide by zero abort), therefore this value should probably have a lower limit of 1. Maybe that packet_limit =3D packets / 3 + 1; would give an acceptably close result in all cases. Else enforce a minimum value of 1 after the division: packet_limit =3D packets / 3; if (packet_limit =3D=3D 0) packet_limit =3D 1; Or just: packet_limit =3D packets >=3D 3 ? packets / 3 : 1= ; Regards, STefan --AfG0Ry9dlrnkfcr2T0uWIqA9mHH9XwLIE-- --W1eXtNstIDZ7j46JgX9A1af8FiCTdxjuL Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEo3HqZZwL7MgrcVMTR+u171r99UQFAmDpWOgFAwAAAAAACgkQR+u171r99UTn dwf/eBtEoBpv7yvsRGzHt6RL61JMIwlqxXOKltE6oaTGKSezGeWRga3IT2KS6g0ghuivvX4XR78I 3tPKWG+n1ylC+tkEkKbC0Aijilg2gy7rr1bM3GINbNL2U9cKTEIDVWqQWCUs+H44aA+jw9nqKhWe UtKBO0GyoCFcSC22I0T27JmTT41icIeWSO34aQgRcoLeB8k+gk9Fz0ngGnqUuBuF40UuMOoRxAwr 8u539r6y1FvtnJ+s0vEZNXVvBYL61OPdDatEo1hh+956lAmCno993TSYJ2CXqlX/q199wXzmA8tn p7Sgf/ejqCibbt4ML3cs1USvP8USHrW6ZYhRHTM+wQ== =sO1Z -----END PGP SIGNATURE----- --W1eXtNstIDZ7j46JgX9A1af8FiCTdxjuL-- From nobody Sat Jul 10 08:52:48 2021 X-Original-To: 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 7A9DECFFA36 for ; Sat, 10 Jul 2021 08:52:50 +0000 (UTC) (envelope-from se@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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 (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GMP1Z2kZ5z3wNg; Sat, 10 Jul 2021 08:52:50 +0000 (UTC) (envelope-from se@freebsd.org) Received: from Stefans-MBP-449.fritz.box (p200300cd5f098700843d0a051b030d69.dip0.t-ipconnect.de [IPv6:2003:cd:5f09:8700:843d:a05:1b03:d69]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: se/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id A020324B43; Sat, 10 Jul 2021 08:52:49 +0000 (UTC) (envelope-from se@freebsd.org) From: Stefan Esser To: Karl Denninger , stable@freebsd.org References: <2e3dcd4d-c8e6-8381-0010-d0844c99901e@denninger.net> <20210708221134.GA32658@belenus.iks-jena.de> <7bfda38b-cf81-d8be-7691-e18946e6b56e@denninger.net> Subject: [PATCH] Re: 12.2 Splay Tree ipfw potential panic source Message-ID: Date: Sat, 10 Jul 2021 10:52:48 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 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 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Zgi5MOsookfrqFKU9tjh27pZMUOG0nWRY" X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Zgi5MOsookfrqFKU9tjh27pZMUOG0nWRY Content-Type: multipart/mixed; boundary="yR5sSIA1NjEBz2dgaD9KVGgCH8obpM7Rd"; protected-headers="v1" From: Stefan Esser To: Karl Denninger , stable@freebsd.org Message-ID: Subject: [PATCH] Re: 12.2 Splay Tree ipfw potential panic source References: <2e3dcd4d-c8e6-8381-0010-d0844c99901e@denninger.net> <20210708221134.GA32658@belenus.iks-jena.de> <7bfda38b-cf81-d8be-7691-e18946e6b56e@denninger.net> In-Reply-To: --yR5sSIA1NjEBz2dgaD9KVGgCH8obpM7Rd Content-Type: multipart/mixed; boundary="------------C0B4A3C089B174697D5ADE38" Content-Language: en-US This is a multi-part message in MIME format. --------------C0B4A3C089B174697D5ADE38 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Am 10.07.21 um 10:23 schrieb Stefan Esser: > Am 10.07.21 um 04:41 schrieb Karl Denninger: >> Ok, so I have good news and bad news. >> >> I have the trap and it is definitely in libalias which appears to come= about as >> a result of a NAT translation attempt. >> >> Fatal trap 18: integer divide fault while in kernel mode > [...] >> HouseKeeping() at HouseKeeping+0x1c/frame 0xfffffe0017b6b320 >=20 > The divide by zero at one of the first instructions of HouseKeeping() > seems to be caused by this line: >=20 > /sys/netinet/libalias/alias_db.c:1753: >=20 > if (packets % packet_limit =3D=3D 0) { >=20 > Seems that packet_limit can become zero, there ... >=20 > At line 1780 within that function: >=20 > if (now !=3D LibAliasTime) { > /* retry three times a second */ > packet_limit =3D packets / 3; > packets =3D 0; > LibAliasTime =3D now; > } >=20 > The static variable packet limit is divided by 3 without any > protection against going down to 0. >=20 > A packet_limit of zero makes no sense (besides causing a divide > by zero abort), therefore this value should probably have a lower > limit of 1. >=20 > Maybe that > packet_limit =3D packets / 3 + 1; >=20 > would give an acceptably close result in all cases. >=20 > Else enforce a minimum value of 1 after the division: >=20 > packet_limit =3D packets / 3; > if (packet_limit =3D=3D 0) > packet_limit =3D 1; > Or just: > packet_limit =3D packets >=3D 3 ? packets / 3 := 1; >=20 > Regards, STefan I have just noticed that enforcing a lower limit of 1 is totally equivalent to testing for zero before performing the modulo operation. The attached patch should fix the panic and does not change the way packet_limit is calculated. Since the variable is immediately used in the modulo when not zero, the additional cost of the test for zero is extremely low, less than that of the other suggested changes. Maybe that increasing packet_limit by 1 is sensible, anyway, since at low packet rates it will result in 0 to 5 packets giving the same effect (the condition in line 1753 evaluates to true). Anyway, please try the attached patch, which will fix the divide by zero panic. Regards, STefan PS: Patch inline in case it is stripped by the mail-list: diff --git a/sys/netinet/libalias/alias_db.c b/sys/netinet/libalias/alias= _db.c index c09ad4352ce4..d5dec0709cbe 100644 --- a/sys/netinet/libalias/alias_db.c +++ b/sys/netinet/libalias/alias_db.c @@ -1769,7 +1769,7 @@ HouseKeeping(struct libalias *la) * Reduce the amount of house keeping work substantially by * sampling over the packets. */ - if (packets % packet_limit =3D=3D 0) { + if (packet_limit =3D=3D 0 || packets % packet_limit =3D=3D 0) { time_t now; #ifdef _KERNEL (Line numbers from -CURRENT, may be slightly off for stable/12.) --------------C0B4A3C089B174697D5ADE38 Content-Type: text/plain; charset=UTF-8; x-mac-type="0"; x-mac-creator="0"; name="libalias-alias_db.diff" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="libalias-alias_db.diff" ZGlmZiAtLWdpdCBhL3N5cy9uZXRpbmV0L2xpYmFsaWFzL2FsaWFzX2RiLmMgYi9zeXMvbmV0 aW5ldC9saWJhbGlhcy9hbGlhc19kYi5jCmluZGV4IGMwOWFkNDM1MmNlNC4uZDVkZWMwNzA5 Y2JlIDEwMDY0NAotLS0gYS9zeXMvbmV0aW5ldC9saWJhbGlhcy9hbGlhc19kYi5jCisrKyBi L3N5cy9uZXRpbmV0L2xpYmFsaWFzL2FsaWFzX2RiLmMKQEAgLTE3NjksNyArMTc2OSw3IEBA IEhvdXNlS2VlcGluZyhzdHJ1Y3QgbGliYWxpYXMgKmxhKQogCSAqIFJlZHVjZSB0aGUgYW1v dW50IG9mIGhvdXNlIGtlZXBpbmcgd29yayBzdWJzdGFudGlhbGx5IGJ5CiAJICogc2FtcGxp bmcgb3ZlciB0aGUgcGFja2V0cy4KIAkgKi8KLQlpZiAocGFja2V0cyAlIHBhY2tldF9saW1p dCA9PSAwKSB7CisJaWYgKHBhY2tldF9saW1pdCA9PSAwIHx8IHBhY2tldHMgJSBwYWNrZXRf bGltaXQgPT0gMCkgewogCQl0aW1lX3Qgbm93OwogCiAjaWZkZWYgX0tFUk5FTAo= --------------C0B4A3C089B174697D5ADE38-- --yR5sSIA1NjEBz2dgaD9KVGgCH8obpM7Rd-- --Zgi5MOsookfrqFKU9tjh27pZMUOG0nWRY Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEo3HqZZwL7MgrcVMTR+u171r99UQFAmDpX+AFAwAAAAAACgkQR+u171r99URf RggAsGOZTBy3K7+vSzQDZnAVdvPbw3XM8Cv1xtVLMRna3/J8WZ03FR3c+AYCDebrrcDPGo8P0niQ ETQjoHKL+gz3cTrFkDAh29oWarzRiB9Bxi1Dw+maLE5Cagv6JBtvyNjvTV5us3jStxIAOI8RzmYw 3mC4oUJQKUFlvTwpwSc2O/oyW2z21kzznNgAwmvNJjuhRX9ZQeOZfYm/hd/Zp3gpbHGpDcP5+uHn cpU5qQjud5rBNSCdzwxifuKhsD0QMU3P6x9yGZg4aCMznZHoQKAtg8V/R6eXrzuNERl5mNmkVaph jlGEUdwMcVtX/DQ1ap9WJY/Hb3ZGtVWXS0L9ctG6wA== =Xxoj -----END PGP SIGNATURE----- --Zgi5MOsookfrqFKU9tjh27pZMUOG0nWRY-- From nobody Sat Jul 10 12:33:51 2021 X-Original-To: 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 B431D8D334A for ; Sat, 10 Jul 2021 12:34:08 +0000 (UTC) (envelope-from lutz@iks-jena.de) Received: from annwfn.iks-jena.de (annwfn.iks-jena.de [IPv6:2001:4bd8::19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4GMTww38xzz4s0b; Sat, 10 Jul 2021 12:34:08 +0000 (UTC) (envelope-from lutz@iks-jena.de) X-SMTP-Sender: IPv6:2001:4bd8:0:666:248:54ff:fe12:ee3f Received: from belenus.iks-jena.de (belenus.iks-jena.de [IPv6:2001:4bd8:0:666:248:54ff:fe12:ee3f]) by annwfn.iks-jena.de (8.15.2/8.15.2) with ESMTPS id 16ACXqxd021228 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 10 Jul 2021 14:33:52 +0200 X-MSA-Host: belenus.iks-jena.de Received: (from lutz@localhost) by belenus.iks-jena.de (8.14.3/8.14.1/Submit) id 16ACXp29030988; Sat, 10 Jul 2021 14:33:51 +0200 Date: Sat, 10 Jul 2021 14:33:51 +0200 From: Lutz Donnerhacke To: Stefan Esser Cc: Karl Denninger , stable@freebsd.org Subject: Re: [PATCH] Re: 12.2 Splay Tree ipfw potential panic source Message-ID: <20210710123351.GA30826@belenus.iks-jena.de> References: <2e3dcd4d-c8e6-8381-0010-d0844c99901e@denninger.net> <20210708221134.GA32658@belenus.iks-jena.de> <7bfda38b-cf81-d8be-7691-e18946e6b56e@denninger.net> 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-message-flag: Please send plain text messages only. Thank you. User-Agent: Mutt/1.5.17 (2007-11-01) X-Rspamd-Queue-Id: 4GMTww38xzz4s0b X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: N On Sat, Jul 10, 2021 at 10:52:48AM +0200, Stefan Esser wrote: > > /sys/netinet/libalias/alias_db.c:1753: > > > > if (packets % packet_limit == 0) { > > > > Seems that packet_limit can become zero, there ... > > > > At line 1780 within that function: > > > > if (now != LibAliasTime) { > > /* retry three times a second */ > > packet_limit = packets / 3; > > packets = 0; > > LibAliasTime = now; > > } Thank you for deducing the reason. Seem to be my fault. I only tested it with heavy traffic. The +1 solution seems to be the best one, because the real number is not important (+100 works, too) and this way the per packet code path is kept to a minimum of instructions. Does a bug ticket exists? I'll issue a review tomorrow. From nobody Sat Jul 10 12:36:29 2021 X-Original-To: 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 0A7C08D43D8 for ; Sat, 10 Jul 2021 12:37:00 +0000 (UTC) (envelope-from karl@denninger.net) Received: from colo1.denninger.net (colo1.denninger.net [104.236.120.189]) (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 4GMV0C6jMQz4t0W; Sat, 10 Jul 2021 12:36:59 +0000 (UTC) (envelope-from karl@denninger.net) Received: from denninger.net (096-033-205-208.res.spectrum.com [96.33.205.208]) by colo1.denninger.net (Postfix) with ESMTP id 302242110D6; Sat, 10 Jul 2021 08:36:28 -0400 (EDT) Received: from [192.168.10.25] (D15.Denninger.Net [192.168.10.25]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by denninger.net (Postfix) with ESMTPSA id C59FC271E9B; Sat, 10 Jul 2021 08:36:28 -0400 (EDT) Subject: Re: [PATCH] Re: 12.2 Splay Tree ipfw potential panic source To: Stefan Esser , stable@freebsd.org References: <2e3dcd4d-c8e6-8381-0010-d0844c99901e@denninger.net> <20210708221134.GA32658@belenus.iks-jena.de> <7bfda38b-cf81-d8be-7691-e18946e6b56e@denninger.net> From: Karl Denninger Message-ID: Date: Sat, 10 Jul 2021 08:36:29 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 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 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms030008070505090303090609" X-Rspamd-Queue-Id: 4GMV0C6jMQz4t0W X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y This is a cryptographically signed message in MIME format. --------------ms030008070505090303090609 Content-Type: multipart/alternative; boundary="------------552FAD09834F85E8D23772B0" Content-Language: en-US This is a multi-part message in MIME format. --------------552FAD09834F85E8D23772B0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable On 7/10/2021 04:52, Stefan Esser wrote: > Am 10.07.21 um 10:23 schrieb Stefan Esser: >> Am 10.07.21 um 04:41 schrieb Karl Denninger: >>> Ok, so I have good news and bad news. >>> >>> I have the trap and it is definitely in libalias which appears to com= e about as >>> a result of a NAT translation attempt. >>> >>> Fatal trap 18: integer divide fault while in kernel mode >> [...] >>> HouseKeeping() at HouseKeeping+0x1c/frame 0xfffffe0017b6b320 >> The divide by zero at one of the first instructions of HouseKeeping() >> seems to be caused by this line: >> >> /sys/netinet/libalias/alias_db.c:1753: >> >> if (packets % packet_limit =3D=3D 0) { >> >> Seems that packet_limit can become zero, there ... >> >> At line 1780 within that function: >> >> if (now !=3D LibAliasTime) { >> /* retry three times a second */ >> packet_limit =3D packets / 3; >> packets =3D 0; >> LibAliasTime =3D now; >> } >> >> The static variable packet limit is divided by 3 without any >> protection against going down to 0. >> >> A packet_limit of zero makes no sense (besides causing a divide >> by zero abort), therefore this value should probably have a lower >> limit of 1. >> >> Maybe that >> packet_limit =3D packets / 3 + 1; >> >> would give an acceptably close result in all cases. >> >> Else enforce a minimum value of 1 after the division: >> >> packet_limit =3D packets / 3; >> if (packet_limit =3D=3D 0) >> packet_limit =3D 1; >> Or just: >> packet_limit =3D packets >=3D 3 ? packets / 3= : 1; >> >> Regards, STefan > I have just noticed that enforcing a lower limit of 1 is totally > equivalent to testing for zero before performing the modulo operation. > > The attached patch should fix the panic and does not change the way > packet_limit is calculated. Since the variable is immediately used > in the modulo when not zero, the additional cost of the test for zero > is extremely low, less than that of the other suggested changes. > > Maybe that increasing packet_limit by 1 is sensible, anyway, since at > low packet rates it will result in 0 to 5 packets giving the same > effect (the condition in line 1753 evaluates to true). > > Anyway, please try the attached patch, which will fix the divide by > zero panic. > > Regards, STefan > > PS: Patch inline in case it is stripped by the mail-list: > > diff --git a/sys/netinet/libalias/alias_db.c b/sys/netinet/libalias/ali= as_db.c > index c09ad4352ce4..d5dec0709cbe 100644 > --- a/sys/netinet/libalias/alias_db.c > +++ b/sys/netinet/libalias/alias_db.c > @@ -1769,7 +1769,7 @@ HouseKeeping(struct libalias *la) > * Reduce the amount of house keeping work substantially by > * sampling over the packets. > */ > - if (packets % packet_limit =3D=3D 0) { > + if (packet_limit =3D=3D 0 || packets % packet_limit =3D=3D 0) {= > time_t now; > > #ifdef _KERNEL > > > (Line numbers from -CURRENT, may be slightly off for stable/12.) Compiling now; I have a roughly hour-long window before a blackout=20 period where I can't have that system crashing until late afternoon.=C2=A0= If=20 I can get it loaded before then will advise but yeah, what you=20 identified would certainly do it if packet_limit became zero...... --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------552FAD09834F85E8D23772B0-- --------------ms030008070505090303090609 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC DdgwggagMIIEiKADAgECAhMA5EiKghDOXrvfxYxjITXYDdhIMA0GCSqGSIb3DQEBCwUAMIGL MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJTmljZXZpbGxlMRkw FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExITAf BgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQTAeFw0xNzA4MTcxNjQyMTdaFw0yNzA4 MTUxNjQyMTdaMHsxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkwFwYDVQQKDBBD dWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExJTAjBgNVBAMMHEN1 ZGEgU3lzdGVtcyBMTEMgMjAxNyBJbnQgQ0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQC1aJotNUI+W4jP7xQDO8L/b4XiF4Rss9O0B+3vMH7Njk85fZ052QhZpMVlpaaO+sCI KqG3oNEbuOHzJB/NDJFnqh7ijBwhdWutdsq23Ux6TvxgakyMPpT6TRNEJzcBVQA0kpby1DVD 0EKSK/FrWWBiFmSxg7qUfmIq/mMzgE6epHktyRM3OGq3dbRdOUgfumWrqHXOrdJz06xE9NzY vc9toqZnd79FUtE/nSZVm1VS3Grq7RKV65onvX3QOW4W1ldEHwggaZxgWGNiR/D4eosAGFxn uYeWlKEC70c99Mp1giWux+7ur6hc2E+AaTGh+fGeijO5q40OGd+dNMgK8Es0nDRw81lRcl24 SWUEky9y8DArgIFlRd6d3ZYwgc1DMTWkTavx3ZpASp5TWih6yI8ACwboTvlUYeooMsPtNa9E 6UQ1nt7VEi5syjxnDltbEFoLYcXBcqhRhFETJe9CdenItAHAtOya3w5+fmC2j/xJz29og1KH YqWHlo3Kswi9G77an+zh6nWkMuHs+03DU8DaOEWzZEav3lVD4u76bKRDTbhh0bMAk4eXriGL h4MUoX3Imfcr6JoyheVrAdHDL/BixbMH1UUspeRuqQMQ5b2T6pabXP0oOB4FqldWiDgJBGRd zWLgCYG8wPGJGYgHibl5rFiI5Ix3FQncipc6SdUzOQIDAQABo4IBCjCCAQYwHQYDVR0OBBYE FF3AXsKnjdPND5+bxVECGKtc047PMIHABgNVHSMEgbgwgbWAFBu1oRhUMNEzjODolDka5k4Q EDBioYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJ TmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5 c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYIJAKxAy1WBo2kY MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3DQEBCwUAA4IC AQCB5686UCBVIT52jO3sz9pKuhxuC2npi8ZvoBwt/IH9piPA15/CGF1XeXUdu2qmhOjHkVLN gO7XB1G8CuluxofOIUce0aZGyB+vZ1ylHXlMeB0R82f5dz3/T7RQso55Y2Vog2Zb7PYTC5B9 oNy3ylsnNLzanYlcW3AAfzZcbxYuAdnuq0Im3EpGm8DoItUcf1pDezugKm/yKtNtY6sDyENj tExZ377cYA3IdIwqn1Mh4OAT/Rmh8au2rZAo0+bMYBy9C11Ex0hQ8zWcvPZBDn4v4RtO8g+K uQZQcJnO09LJNtw94W3d2mj4a7XrsKMnZKvm6W9BJIQ4Nmht4wXAtPQ1xA+QpxPTmsGAU0Cv HmqVC7XC3qxFhaOrD2dsvOAK6Sn3MEpH/YrfYCX7a7cz5zW3DsJQ6o3pYfnnQz+hnwLlz4MK 17NIA0WOdAF9IbtQqarf44+PEyUbKtz1r0KGeGLs+VGdd2FLA0e7yuzxJDYcaBTVwqaHhU2/ Fna/jGU7BhrKHtJbb/XlLeFJ24yvuiYKpYWQSSyZu1R/gvZjHeGb344jGBsZdCDrdxtQQcVA 6OxsMAPSUPMrlg9LWELEEYnVulQJerWxpUecGH92O06wwmPgykkz//UmmgjVSh7ErNvL0lUY UMfunYVO/O5hwhW+P4gviCXzBFeTtDZH259O7TCCBzAwggUYoAMCAQICEwCg0WvVwekjGFiO 62SckFwepz0wDQYJKoZIhvcNAQELBQAwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3Jp ZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBD QTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExMQyAyMDE3IEludCBDQTAeFw0xNzA4MTcyMTIx MjBaFw0yMjA4MTYyMTIxMjBaMFcxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkw FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRswGQYDVQQDDBJrYXJsQGRlbm5pbmdlci5uZXQw ggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQC+HVSyxVtJhy3Ohs+PAGRuO//Dha9A 16l5FPATr6wude9zjX5f2lrkRyU8vhCXTZW7WbvWZKpcZ8r0dtZmiK9uF58Ec6hhvfkxJzbg 96WHBw5Fumd5ahZzuCJDtCAWW8R7/KN+zwzQf1+B3MVLmbaXAFBuKzySKhKMcHbK3/wjUYTg y+3UK6v2SBrowvkUBC+jxNg3Wy12GsTXcUS/8FYIXgVVPgfZZrbJJb5HWOQpvvhILpPCD3xs YJFNKEPltXKWHT7Qtc2HNqikgNwj8oqOb+PeZGMiWapsatKm8mxuOOGOEBhAoTVTwUHlMNTg 6QUCJtuWFCK38qOCyk9Haj+86lUU8RG6FkRXWgMbNQm1mWREQhw3axgGLSntjjnznJr5vsvX SYR6c+XKLd5KQZcS6LL8FHYNjqVKHBYM+hDnrTZMqa20JLAF1YagutDiMRURU23iWS7bA9tM cXcqkclTSDtFtxahRifXRI7Epq2GSKuEXe/1Tfb5CE8QsbCpGsfSwv2tZ/SpqVG08MdRiXxN 5tmZiQWo15IyWoeKOXl/hKxA9KPuDHngXX022b1ly+5ZOZbxBAZZMod4y4b4FiRUhRI97r9l CxsP/EPHuuTIZ82BYhrhbtab8HuRo2ofne2TfAWY2BlA7ExM8XShMd9bRPZrNTokPQPUCWCg CdIATQIDAQABo4IBzzCCAcswPAYIKwYBBQUHAQEEMDAuMCwGCCsGAQUFBzABhiBodHRwOi8v b2NzcC5jdWRhc3lzdGVtcy5uZXQ6ODg4ODAJBgNVHRMEAjAAMBEGCWCGSAGG+EIBAQQEAwIF oDAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMDMGCWCG SAGG+EIBDQQmFiRPcGVuU1NMIEdlbmVyYXRlZCBDbGllbnQgQ2VydGlmaWNhdGUwHQYDVR0O BBYEFLElmNWeVgsBPe7O8NiBzjvjYnpRMIHKBgNVHSMEgcIwgb+AFF3AXsKnjdPND5+bxVEC GKtc047PoYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UE BwwJTmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRh IFN5c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYITAORIioIQ zl6738WMYyE12A3YSDAdBgNVHREEFjAUgRJrYXJsQGRlbm5pbmdlci5uZXQwDQYJKoZIhvcN AQELBQADggIBAJXboPFBMLMtaiUt4KEtJCXlHO/3ZzIUIw/eobWFMdhe7M4+0u3te0sr77QR dcPKR0UeHffvpth2Mb3h28WfN0FmJmLwJk+pOx4u6uO3O0E1jNXoKh8fVcL4KU79oEQyYkbu 2HwbXBU9HbldPOOZDnPLi0whi/sbFHdyd4/w/NmnPgzAsQNZ2BYT9uBNr+jZw4SsluQzXG1X lFL/qCBoi1N2mqKPIepfGYF6drbr1RnXEJJsuD+NILLooTNf7PMgHPZ4VSWQXLNeFfygoOOK FiO0qfxPKpDMA+FHa8yNjAJZAgdJX5Mm1kbqipvb+r/H1UAmrzGMbhmf1gConsT5f8KU4n3Q IM2sOpTQe7BoVKlQM/fpQi6aBzu67M1iF1WtODpa5QUPvj1etaK+R3eYBzi4DIbCIWst8MdA 1+fEeKJFvMEZQONpkCwrJ+tJEuGQmjoQZgK1HeloepF0WDcviiho5FlgtAij+iBPtwMuuLiL shAXA5afMX1hYM4l11JXntle12EQFP1r6wOUkpOdxceCcMVDEJBBCHW2ZmdEaXgAm1VU+fnQ qS/wNw/S0X3RJT1qjr5uVlp2Y0auG/eG0jy6TT0KzTJeR9tLSDXprYkN2l/Qf7/nT6Q03qyE QnnKiBXWAZXveafyU/zYa7t3PTWFQGgWoC4w6XqgPo4KV44OMYIFBzCCBQMCAQEwgZIwezEL MAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBM TEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExM QyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTANBglghkgBZQMEAgMFAKCCAkUw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjEwNzEwMTIzNjI5 WjBPBgkqhkiG9w0BCQQxQgRA/kfC70R8RdG2Keo47IDew6CEBuv9GFyI6mAi6P8Ww9Ke5il6 dtK3XsaHq6aECt+D9a8dIL8OLPNUIfgrYA63LDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFl AwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3 DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGjBgkrBgEEAYI3EAQxgZUwgZIwezEL MAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBM TEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExM QyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTCBpQYLKoZIhvcNAQkQAgsxgZWg gZIwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lz dGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0 ZW1zIExMQyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTANBgkqhkiG9w0BAQEF AASCAgBxglnX99LdA7T2vi6OBuMcCjMsWc/h160ROvnOYJhJ0P/p1olTLVbyR5XpooGIpZNV IaiTJmGA3HsaYM4VtDZt3x23PZ0vlrsGrhQ0EPW0SgpxKXfoAqEHphDn31dp4yT1Fz6E6iOW uDXv6HoHYTvRRV5KgKv+MeNg5Rl0BX+DoGKSRp7YsraXBmXV9GbXxd4unHRdbaceIDJdZYVM b37/huueCgGNhVAOQ7bzeBYNhPQxxclSVWPrrOUDQZ7eoMoLYw1wec0QPt2qYtRs8EyvVpIB glsEyEDmhIYVzRkgJUOS8MoOpqYFo3sW45n/ricq1gV93Ytt4aVx1M0ajKPW9lEgx33n39bW rZf+l+cPdq5VMuZN0lE9CUjOc0HGrOLu00YOKaziOgrBUABqDG5PJrh7TtrFyjpXPosk6m8A n9e9rYkhLia6YXpuXyfVS3K6/huVUCSDpIah+cVXmIjnSFbwLlKNCnTJ0LrTptuEjrdglDWO sU5fVhF6qfXmT0rX6cXtdNwOtYKW3Pbj4NSKCxhdHEtelDqNQxaf1sF+rr4xgOFWYo/ndlny 3C46daEWoZnqj1pZ6L08euTFZ/esK7EeqHmp/ADmWLjPJ/XM9A+yCeHjICWDhgFQzWhUVssQ /NhG9tGXSHOAVKPalVyvSMBjB9rtBvtuA+Ic447b4gAAAAAAAA== --------------ms030008070505090303090609-- From nobody Sat Jul 10 12:55:00 2021 X-Original-To: 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 AE20C8D6F4D for ; Sat, 10 Jul 2021 12:55:07 +0000 (UTC) (envelope-from lutz@iks-jena.de) Received: from annwfn.iks-jena.de (annwfn.iks-jena.de [IPv6:2001:4bd8::19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4GMVP64kH0z3C11; Sat, 10 Jul 2021 12:55:06 +0000 (UTC) (envelope-from lutz@iks-jena.de) X-SMTP-Sender: IPv6:2001:4bd8:0:666:248:54ff:fe12:ee3f Received: from belenus.iks-jena.de (belenus.iks-jena.de [IPv6:2001:4bd8:0:666:248:54ff:fe12:ee3f]) by annwfn.iks-jena.de (8.15.2/8.15.2) with ESMTPS id 16ACt0eX024079 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 10 Jul 2021 14:55:00 +0200 X-MSA-Host: belenus.iks-jena.de Received: (from lutz@localhost) by belenus.iks-jena.de (8.14.3/8.14.1/Submit) id 16ACt0Wn031459; Sat, 10 Jul 2021 14:55:00 +0200 Date: Sat, 10 Jul 2021 14:55:00 +0200 From: Lutz Donnerhacke To: Stefan Esser Cc: Karl Denninger , stable@freebsd.org Subject: Re: 12.2 Splay Tree ipfw potential panic source Message-ID: <20210710125500.GA31426@belenus.iks-jena.de> References: <2e3dcd4d-c8e6-8381-0010-d0844c99901e@denninger.net> <20210708221134.GA32658@belenus.iks-jena.de> <7bfda38b-cf81-d8be-7691-e18946e6b56e@denninger.net> <20210710123351.GA30826@belenus.iks-jena.de> 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: <20210710123351.GA30826@belenus.iks-jena.de> X-message-flag: Please send plain text messages only. Thank you. User-Agent: Mutt/1.5.17 (2007-11-01) X-Rspamd-Queue-Id: 4GMVP64kH0z3C11 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of lutz@iks-jena.de designates 2001:4bd8::19 as permitted sender) smtp.mailfrom=lutz@iks-jena.de X-Spamd-Result: default: False [-2.98 / 15.00]; ARC_NA(0.00)[]; MAILMAN_DEST(0.00)[stable]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2001:4bd8::/48]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[donnerhacke.de]; RBL_DBL_DONT_QUERY_IPS(0.00)[2001:4bd8::19:from]; SPAMHAUS_ZRD(0.00)[2001:4bd8::19:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.98)[-0.979]; FORGED_SENDER(0.30)[lutz@donnerhacke.de,lutz@iks-jena.de]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; FROM_NEQ_ENVFROM(0.00)[lutz@donnerhacke.de,lutz@iks-jena.de]; ASN(0.00)[asn:15725, ipnet:2001:4bd8::/29, country:DE] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: N On Sat, Jul 10, 2021 at 02:33:51PM +0200, Lutz Donnerhacke wrote: > I'll issue a review tomorrow. Thank you @se for adding the hotfix. So we have time to find a longer term solution. https://reviews.freebsd.org/D31132 From nobody Sat Jul 10 13:44:08 2021 X-Original-To: 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 4F75511E6B92 for ; Sat, 10 Jul 2021 13:44:10 +0000 (UTC) (envelope-from karl@denninger.net) Received: from colo1.denninger.net (colo1.denninger.net [104.236.120.189]) (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 4GMWTj4FC2z3KGg for ; Sat, 10 Jul 2021 13:44:09 +0000 (UTC) (envelope-from karl@denninger.net) Received: from denninger.net (096-033-205-208.res.spectrum.com [96.33.205.208]) by colo1.denninger.net (Postfix) with ESMTP id 29AC5211089 for ; Sat, 10 Jul 2021 09:44:08 -0400 (EDT) Received: from [192.168.10.25] (D15.Denninger.Net [192.168.10.25]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by denninger.net (Postfix) with ESMTPSA id A4B8BA6C16 for ; Sat, 10 Jul 2021 09:44:08 -0400 (EDT) Subject: Re: 12.2 Splay Tree ipfw potential panic source To: stable@freebsd.org References: <2e3dcd4d-c8e6-8381-0010-d0844c99901e@denninger.net> <20210708221134.GA32658@belenus.iks-jena.de> <7bfda38b-cf81-d8be-7691-e18946e6b56e@denninger.net> <20210710123351.GA30826@belenus.iks-jena.de> <20210710125500.GA31426@belenus.iks-jena.de> From: Karl Denninger Message-ID: <934cf54b-e993-1221-38e0-4c5287f9d536@denninger.net> Date: Sat, 10 Jul 2021 09:44:08 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 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 In-Reply-To: <20210710125500.GA31426@belenus.iks-jena.de> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms020903010905080006070007" X-Rspamd-Queue-Id: 4GMWTj4FC2z3KGg X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=denninger.net; spf=pass (mx1.freebsd.org: domain of karl@denninger.net designates 104.236.120.189 as permitted sender) smtp.mailfrom=karl@denninger.net X-Spamd-Result: default: False [-4.04 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; HAS_ATTACHMENT(0.00)[]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DMARC_POLICY_ALLOW(-0.50)[denninger.net,none]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[104.236.120.189:from]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:14061, ipnet:104.236.64.0/18, country:US]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEFALL_USER(0.00)[karl]; FROM_HAS_DN(0.00)[]; SIGNED_SMIME(-2.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,multipart/alternative,text/plain]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:~]; PREVIOUSLY_DELIVERED(0.00)[stable@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[104.236.120.189:from:127.0.2.255]; NEURAL_SPAM_SHORT(0.86)[0.857]; MAILMAN_DEST(0.00)[stable] X-ThisMailContainsUnwantedMimeParts: Y This is a cryptographically signed message in MIME format. --------------ms020903010905080006070007 Content-Type: multipart/alternative; boundary="------------C07E94C9284E32E5D514B30B" Content-Language: en-US This is a multi-part message in MIME format. --------------C07E94C9284E32E5D514B30B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable At first blush the hotfix appears effective; said box has 17 minutes of=20 uptime on it with the patch, which is more than double the best without=20 it..... On 7/10/2021 08:55, Lutz Donnerhacke wrote: > On Sat, Jul 10, 2021 at 02:33:51PM +0200, Lutz Donnerhacke wrote: >> I'll issue a review tomorrow. > Thank you @se for adding the hotfix. > So we have time to find a longer term solution. > https://reviews.freebsd.org/D31132 > --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------C07E94C9284E32E5D514B30B-- --------------ms020903010905080006070007 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC DdgwggagMIIEiKADAgECAhMA5EiKghDOXrvfxYxjITXYDdhIMA0GCSqGSIb3DQEBCwUAMIGL MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJTmljZXZpbGxlMRkw FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExITAf BgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQTAeFw0xNzA4MTcxNjQyMTdaFw0yNzA4 MTUxNjQyMTdaMHsxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkwFwYDVQQKDBBD dWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExJTAjBgNVBAMMHEN1 ZGEgU3lzdGVtcyBMTEMgMjAxNyBJbnQgQ0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQC1aJotNUI+W4jP7xQDO8L/b4XiF4Rss9O0B+3vMH7Njk85fZ052QhZpMVlpaaO+sCI KqG3oNEbuOHzJB/NDJFnqh7ijBwhdWutdsq23Ux6TvxgakyMPpT6TRNEJzcBVQA0kpby1DVD 0EKSK/FrWWBiFmSxg7qUfmIq/mMzgE6epHktyRM3OGq3dbRdOUgfumWrqHXOrdJz06xE9NzY vc9toqZnd79FUtE/nSZVm1VS3Grq7RKV65onvX3QOW4W1ldEHwggaZxgWGNiR/D4eosAGFxn uYeWlKEC70c99Mp1giWux+7ur6hc2E+AaTGh+fGeijO5q40OGd+dNMgK8Es0nDRw81lRcl24 SWUEky9y8DArgIFlRd6d3ZYwgc1DMTWkTavx3ZpASp5TWih6yI8ACwboTvlUYeooMsPtNa9E 6UQ1nt7VEi5syjxnDltbEFoLYcXBcqhRhFETJe9CdenItAHAtOya3w5+fmC2j/xJz29og1KH YqWHlo3Kswi9G77an+zh6nWkMuHs+03DU8DaOEWzZEav3lVD4u76bKRDTbhh0bMAk4eXriGL h4MUoX3Imfcr6JoyheVrAdHDL/BixbMH1UUspeRuqQMQ5b2T6pabXP0oOB4FqldWiDgJBGRd zWLgCYG8wPGJGYgHibl5rFiI5Ix3FQncipc6SdUzOQIDAQABo4IBCjCCAQYwHQYDVR0OBBYE FF3AXsKnjdPND5+bxVECGKtc047PMIHABgNVHSMEgbgwgbWAFBu1oRhUMNEzjODolDka5k4Q EDBioYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJ TmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5 c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYIJAKxAy1WBo2kY MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3DQEBCwUAA4IC AQCB5686UCBVIT52jO3sz9pKuhxuC2npi8ZvoBwt/IH9piPA15/CGF1XeXUdu2qmhOjHkVLN gO7XB1G8CuluxofOIUce0aZGyB+vZ1ylHXlMeB0R82f5dz3/T7RQso55Y2Vog2Zb7PYTC5B9 oNy3ylsnNLzanYlcW3AAfzZcbxYuAdnuq0Im3EpGm8DoItUcf1pDezugKm/yKtNtY6sDyENj tExZ377cYA3IdIwqn1Mh4OAT/Rmh8au2rZAo0+bMYBy9C11Ex0hQ8zWcvPZBDn4v4RtO8g+K uQZQcJnO09LJNtw94W3d2mj4a7XrsKMnZKvm6W9BJIQ4Nmht4wXAtPQ1xA+QpxPTmsGAU0Cv HmqVC7XC3qxFhaOrD2dsvOAK6Sn3MEpH/YrfYCX7a7cz5zW3DsJQ6o3pYfnnQz+hnwLlz4MK 17NIA0WOdAF9IbtQqarf44+PEyUbKtz1r0KGeGLs+VGdd2FLA0e7yuzxJDYcaBTVwqaHhU2/ Fna/jGU7BhrKHtJbb/XlLeFJ24yvuiYKpYWQSSyZu1R/gvZjHeGb344jGBsZdCDrdxtQQcVA 6OxsMAPSUPMrlg9LWELEEYnVulQJerWxpUecGH92O06wwmPgykkz//UmmgjVSh7ErNvL0lUY UMfunYVO/O5hwhW+P4gviCXzBFeTtDZH259O7TCCBzAwggUYoAMCAQICEwCg0WvVwekjGFiO 62SckFwepz0wDQYJKoZIhvcNAQELBQAwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3Jp ZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBD QTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExMQyAyMDE3IEludCBDQTAeFw0xNzA4MTcyMTIx MjBaFw0yMjA4MTYyMTIxMjBaMFcxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkw FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRswGQYDVQQDDBJrYXJsQGRlbm5pbmdlci5uZXQw ggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQC+HVSyxVtJhy3Ohs+PAGRuO//Dha9A 16l5FPATr6wude9zjX5f2lrkRyU8vhCXTZW7WbvWZKpcZ8r0dtZmiK9uF58Ec6hhvfkxJzbg 96WHBw5Fumd5ahZzuCJDtCAWW8R7/KN+zwzQf1+B3MVLmbaXAFBuKzySKhKMcHbK3/wjUYTg y+3UK6v2SBrowvkUBC+jxNg3Wy12GsTXcUS/8FYIXgVVPgfZZrbJJb5HWOQpvvhILpPCD3xs YJFNKEPltXKWHT7Qtc2HNqikgNwj8oqOb+PeZGMiWapsatKm8mxuOOGOEBhAoTVTwUHlMNTg 6QUCJtuWFCK38qOCyk9Haj+86lUU8RG6FkRXWgMbNQm1mWREQhw3axgGLSntjjnznJr5vsvX SYR6c+XKLd5KQZcS6LL8FHYNjqVKHBYM+hDnrTZMqa20JLAF1YagutDiMRURU23iWS7bA9tM cXcqkclTSDtFtxahRifXRI7Epq2GSKuEXe/1Tfb5CE8QsbCpGsfSwv2tZ/SpqVG08MdRiXxN 5tmZiQWo15IyWoeKOXl/hKxA9KPuDHngXX022b1ly+5ZOZbxBAZZMod4y4b4FiRUhRI97r9l CxsP/EPHuuTIZ82BYhrhbtab8HuRo2ofne2TfAWY2BlA7ExM8XShMd9bRPZrNTokPQPUCWCg CdIATQIDAQABo4IBzzCCAcswPAYIKwYBBQUHAQEEMDAuMCwGCCsGAQUFBzABhiBodHRwOi8v b2NzcC5jdWRhc3lzdGVtcy5uZXQ6ODg4ODAJBgNVHRMEAjAAMBEGCWCGSAGG+EIBAQQEAwIF oDAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMDMGCWCG SAGG+EIBDQQmFiRPcGVuU1NMIEdlbmVyYXRlZCBDbGllbnQgQ2VydGlmaWNhdGUwHQYDVR0O BBYEFLElmNWeVgsBPe7O8NiBzjvjYnpRMIHKBgNVHSMEgcIwgb+AFF3AXsKnjdPND5+bxVEC GKtc047PoYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UE BwwJTmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRh IFN5c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYITAORIioIQ zl6738WMYyE12A3YSDAdBgNVHREEFjAUgRJrYXJsQGRlbm5pbmdlci5uZXQwDQYJKoZIhvcN AQELBQADggIBAJXboPFBMLMtaiUt4KEtJCXlHO/3ZzIUIw/eobWFMdhe7M4+0u3te0sr77QR dcPKR0UeHffvpth2Mb3h28WfN0FmJmLwJk+pOx4u6uO3O0E1jNXoKh8fVcL4KU79oEQyYkbu 2HwbXBU9HbldPOOZDnPLi0whi/sbFHdyd4/w/NmnPgzAsQNZ2BYT9uBNr+jZw4SsluQzXG1X lFL/qCBoi1N2mqKPIepfGYF6drbr1RnXEJJsuD+NILLooTNf7PMgHPZ4VSWQXLNeFfygoOOK FiO0qfxPKpDMA+FHa8yNjAJZAgdJX5Mm1kbqipvb+r/H1UAmrzGMbhmf1gConsT5f8KU4n3Q IM2sOpTQe7BoVKlQM/fpQi6aBzu67M1iF1WtODpa5QUPvj1etaK+R3eYBzi4DIbCIWst8MdA 1+fEeKJFvMEZQONpkCwrJ+tJEuGQmjoQZgK1HeloepF0WDcviiho5FlgtAij+iBPtwMuuLiL shAXA5afMX1hYM4l11JXntle12EQFP1r6wOUkpOdxceCcMVDEJBBCHW2ZmdEaXgAm1VU+fnQ qS/wNw/S0X3RJT1qjr5uVlp2Y0auG/eG0jy6TT0KzTJeR9tLSDXprYkN2l/Qf7/nT6Q03qyE QnnKiBXWAZXveafyU/zYa7t3PTWFQGgWoC4w6XqgPo4KV44OMYIFBzCCBQMCAQEwgZIwezEL MAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBM TEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExM QyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTANBglghkgBZQMEAgMFAKCCAkUw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjEwNzEwMTM0NDA5 WjBPBgkqhkiG9w0BCQQxQgRAOfdj4fIAEpuXnkW+FDA6MQYjMdjuYoSQ4wAL2g2DrmHV8sK5 /VaEQbjhQ3JjuvTRrnGBufd94QWkw58GVwGvgjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFl AwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3 DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGjBgkrBgEEAYI3EAQxgZUwgZIwezEL MAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBM TEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExM QyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTCBpQYLKoZIhvcNAQkQAgsxgZWg gZIwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lz dGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0 ZW1zIExMQyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTANBgkqhkiG9w0BAQEF AASCAgBkTSedCCXyaWYCORXG48P0oE1t/AaqRMzVijv1xKHZy8nrg3moAXdYyjeY26GxbSWx GNzL8YiICUXg+OHwqLtu0Nmjnb3oSTMRSR1/ZHoHN1pA8vpkLlD7c6uIxv58cvEwC5dSYsqc aKvh9IgaXDV74wheGl3Q+iTPmRmBv2AyGNvGRfGbozM1kEUQl+TigOl5xMRudXgaGyeLbesU Y9kJjifFSn2ke3yEFQRHqDrmYlHlb+7Fz3mkHQxXZN9hg8mROiie2KpglHciYlEeapWlXZaF pj8itesF1Uf1zUNx/xbjjoKF0ZzQWDE4kFif1KAcUd1iVYWSNDdkbPwANm6/h+BqlJEhcokq iPZ0J/p3++ofXwPASRM5UBQvWdlfwsX9/LgJ6MD/YcxqdH+OvFz+WnU2tZJkEJh4IEg88b7k 0mgDNLuxiwhHy7Gw+APPrjz6jxcuEknOvyRBkP0JZ7G05VNirnvErzX7TvT8+vd4/za73ytO pv1J9njfKSbvyTgReQw8tm7dYfTjgAfH4Tx6p/LqbT+yEKQEqvTFyKGQxhycXGy0e6UcDplV pmWVLuLFXjE7E8cn3hYcTSID0PMyfP07FQ1plvHxFGgv8aP0721Lv+qrArgnUj1lqO9MWmKQ CphW5VBRpsxYq5QR4xV0qXoA1p2Ve9uOy+RBl8rROQAAAAAAAA== --------------ms020903010905080006070007--