From owner-freebsd-hackers@freebsd.org Sun May 10 07:55:20 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 3DE442DD18D for ; Sun, 10 May 2020 07:55:20 +0000 (UTC) (envelope-from joel.bertrand@systella.fr) Received: from rayleigh.systella.fr (newton-ipv6.systella.fr [IPv6:2001:7a8:a8ed:253::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "*.systella.fr", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49Kbvp6MYnz3Myc; Sun, 10 May 2020 07:55:18 +0000 (UTC) (envelope-from joel.bertrand@systella.fr) Received: from [192.168.10.103] (hilbert.systella.fr [192.168.10.103]) (authenticated bits=0) by rayleigh.systella.fr (8.15.2/8.15.2/Debian-16) with ESMTPSA id 04A7stme743103 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT); Sun, 10 May 2020 09:54:56 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=systella.fr; s=mail; t=1589097297; bh=EkUqYUB5Cf4+7vozLD99y84JLt/UWlpjYPa7L7zZYCU=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=UlqdQvZxVv2OoHNMK/3NIdmQa/d6eQNxgNUSdDua597qOscEhWo3+tCljigkBVMCg e31lq2X5hUT4Nq8qKUcGNirrH9ovMt5I3FvbwoSzwNebMOMLdB5hh5gXf9Y+ZhI5uA EeKn94MmY2Ndz4XmYevdlaqbmFabyXPbV0htW+HU9YLUKYkaBWkmUHEdZ0td5y2GUA YLJcUroKY9ikSAr/JG+nd/xBAzF37qQEpumSoKyqQoDI7pecHrcdaLO4GRXpu6jeln KTpNV6vlk1GzN2H+UhRrE8VMMZhqcfdk9NRVs7zt+tOL+vmY46ifq03/mgvtFjeq7i yptf2oaPjBFOA== Subject: Re: Segfault on some applications using qt5 To: cem@freebsd.org Cc: "freebsd-hackers@freebsd.org" References: <695d2c45-9901-3f3e-ec7d-d11b75efa8e6@systella.fr> <95cabd0b-8384-5fa1-6e9a-e5f2e24f1bac@systella.fr> From: =?UTF-8?Q?BERTRAND_Jo=c3=abl?= Openpgp: preference=signencrypt Autocrypt: addr=joel.bertrand@systella.fr; prefer-encrypt=mutual; keydata= mQINBFphqV8BEAC+ye6YQBdlEn9p/mbZhiQLkZQjIbGL84M0XOd66AgWqJ3T2TiwEyiExQyM Of0VswmB1q6SaIyh0x4bzaRyKwJLWDJy+AMGLGT2cpmsrDgllUxiBv3xAoLpwR8yDuLs5+bT vPpu81Pm/nzO2NDl85+3WAQbW+bUDAUdBhkg7X07bjJePypRxoRh4LF/syalOjzPEFARFNBY VrXFCTS/F7ZwmUHLv2xWJpEyKHfsC4BSo4ZPjrKmPJBxBPxuR+KiSYG/TkjU6CzoFvdwRY33 GNrK+dUmt9/VnPC/l1rGWS3durgah4OEkxciesKiTvQBUzVfMY0dvzBQKJeNNMFLstnjq3NP qvo3g5DnhFYFSAjI7wzqLkcYO8qg01wrWYyY/NLfAY6CvK0VjlenlKu84ePQDu7zh9/DUzBs 75ZAP2vZv4o00B2A3ksbkXSIs9eSDDx19OS1EUkSqw1VtFRfupoMkK7I7zrGR+DBENl5oK09 SOYJw594XVAoPpZ5zVUlEBDpatBNICTTT17EHrVpEB222TVfChvoE0cwYGkS40nVRIhQ1Yo3 A8qeKb2EeeCtslgiNcb1ajeZOSGUSHnczWHTaX5jMB/evNxZpLJH1WX8PqZ/+7wVRYuZGZ/b r8V3wXjZVNzPSTONwq3w/VjizPcQqdwicoNtxvuB6hM1J1tLGQARAQABtCpCRVJUUkFORCBK b8OrbCA8am9lbC5iZXJ0cmFuZEBzeXN0ZWxsYS5mcj6JAlQEEwEKAD4WIQSrhgKgAkzAsSVl Vhc4B+jSUpDz5wUCWmGpXwIbIwUJCWYBgAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRA4 B+jSUpDz5xwED/462ki+I97keYMSDPVjzx9MmcE/pznOqv8b4IbFbWzaSCx5J3BByBVU1IyP LdDCdZgvc7vM5l8Gc6mqxeABbgdyxBGMwoXBBADXt9dcAKW3xl6URMLoor8DwgnuluCdQT+K 7VW6ron23x7wI9iscuXV2M6xG2G84o5kDgW2NrkKBIwfWqS/XATNrC8e9j71h29cv1RvKN2a 3XQMI6kvBRirb9zM8jWaP1K/QCLZpvhuiXCJwJvl+MGTuOUTxvp44MjVaM++Wfljc9NAVyD8 s3UxBTjhei1zIHiLUMANzeFLnW21UnoCLLoqzD558VC2Gyqk9I9kaZ/jgQqEu6drbJG+6LbY zbiYt1OhURCrMh7zXjPbBCF1rjtjhEZx2EmT2U7KWQvgcW75JBEGCRveTXQga8ytBTcNoEC8 e7ZjM0ob769ZQ1HmeWAOJy6xKEnv1A2P3erQ3xTZEHFVesoruhMAzrf2fdWJ9vGvndMt7sV/ G0NabDwlI+eIZ77vEUCdFiCZuE8vk0BglwXHVH5zjgJNVLNgNFSs3uTSf5zOIqLXyQTOd0px 5jNe2mePxdMuI9MuQWXE8Z7InUaU1WZ+95eTMonTs+DRUJzQ+XWYbqllGudx230T/Y6cYxSW stw5bAQl1aNhNCZjHutNUigb8row2cH2kCVJexv4LYUx8vdc2bkCDQRaYalfARAA000pOiAt CMcbNPczj/sFU5UZ6zaEOPj08nNv48UZAfo8ZiWejSp7YbaU4HW0VxcT2ZQvhsHor2wjqI5K Ii7gmGyjMA6NJPhHVoJw8+j64m38mRcOzlSaQEZV+Pp+TAX8PyucZvNPXHy40UQfDqCoYxAw A0bSWwcSwH+N/eEijrEOf7k1QRjEodjGTxaE50XOWXz/NMVx7l9ORcd5r2oq2DLjqnnQzl6k XxmxSV5cm+HDIojLmQz1qxq7r2GhC5hGuR5KXrO/p4bNiqCTw+rwm4bO6YjTfaH+eNRwzg6L OpW7ZNw0pfWf4wO/h+ozZTY5q9EbZSmZyVoSyPu2J1+mX3gF2ZLSzZ7+XgV4z6EIAcF1sjGE hsqA9yF4NVHGlrP9dkhZFoBVtkJgjSfdSWGXp40X+pUROeVuexD6zDadB5rCv05o9/EPDFu0 W7mJ+l8h3rGI0E5ObmR6+HyFGqalByGFxYbia+x51Kj6WbHNMuddkPk0YbHs53zS9VGnRcnh xTGdga2rMzO9ZycKo7DPrdZVi7bZWKM/WM0IL5m6FTPSJteJ886NP9oc8U6o2GxZ1cMeZwnu AprT77mISL0Z1CCcoSDZEnD+EmOcKxYnkxJuhMY2kdMd2x47I2HFxTa1ix6UQ7OY6i0VQ4gG WZ3tgiHYIHbeAyZXn0P4nM5ofgEAEQEAAYkCPAQYAQoAJhYhBKuGAqACTMCxJWVWFzgH6NJS kPPnBQJaYalfAhsMBQkJZgGAAAoJEDgH6NJSkPPn9mEP/2mEFZGT0AaecRRXfpfrVnxxIwK8 YK3mmaa8jqSLXzDgubTO6PWojVt/SCrvhCtEf5vxATPbeFz5Ho0foI/iGys9SQkYmsIn13m0 z9oY8LBIyrPFud56RrIqYBno3qR6N7SWBWtZeUw+gc6HYbMyk2L7//wz4DkneJYLLcTfMxb/ +Ok0tNmWp6YfuyRBt5yHU6VfW4tZxF5qzg+9niW3VbB6BEZbM+ya7qBZD8su4e1EfUjaKb2z Egyw09laSgBW4NzGBwlhX3zeDsNTiReqa78e1pv52Ur3dI5GH4psLw4rH7ghh/aA/eVDMcKn LPNeTNl+Sz/1PK+oVNxz6tGBVsTVbZpwbanv6+qQP3yPvX0MS1x5QQPp/SAsjJv6lpFkoUGK n2clMYH8pSefR7jp0UPCrMBeFv5bom8tNMTHrIQrpnWo7vXUmeJ7OP/lHUtbBB26882pYbpa 05D79xUkBMYX2BGvtM687+CZaWwA4u/Tl7cu3PpIavPWgmmvIBJOwsDKxNgopLkix8AGFbfs wPcE7d03t9tdauheHA8pssNQmy3scoThC3DQc4eIEBUU5M9uIW2HARl3OgJP9h9OePsgaT8g zTlN3q6QmDWQwRmxF6J7Z9dtIDmXr+014XtK7UCzxkBIFS5jPGzL8dSKDu5jIx8cboy9QUeH Tr6FXnLg Message-ID: <5c6b3ba1-0683-e42a-ee01-1c698425d733@systella.fr> Date: Sun, 10 May 2020 09:54:55 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0 SeaMonkey/2.53.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.102.1 at rayleigh X-Virus-Status: Clean X-Rspamd-Queue-Id: 49Kbvp6MYnz3Myc X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=systella.fr header.s=mail header.b=UlqdQvZx; dmarc=none; spf=pass (mx1.freebsd.org: domain of joel.bertrand@systella.fr designates 2001:7a8:a8ed:253::1 as permitted sender) smtp.mailfrom=joel.bertrand@systella.fr X-Spamd-Result: default: False [-1.39 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_ALLOW(-0.20)[systella.fr:s=mail]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2001:7a8:a8ed:253::1/64]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[systella.fr]; NEURAL_HAM_LONG(-0.83)[-0.827,0]; NEURAL_HAM_MEDIUM(-0.79)[-0.786,0]; DKIM_TRACE(0.00)[systella.fr:+]; RCPT_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; IP_SCORE(0.72)[asn: 13193(3.60), country: FR(-0.00)]; ASN(0.00)[asn:13193, ipnet:2001:7a8::/32, country:FR]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 May 2020 07:55:20 -0000 Conrad Meyer a écrit : > Great, thanks! > Hi Conrad, Were you able to reproduce these segfaults ? I have tried to solve them without any success. I can also open ssh access on this workstation if you want. Best regards, JKB From owner-freebsd-hackers@freebsd.org Sun May 10 15:42:20 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id A38652EAE00 for ; Sun, 10 May 2020 15:42:20 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 49KpGh17lTz4Kqg for ; Sun, 10 May 2020 15:42:20 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: by mailman.nyi.freebsd.org (Postfix) id 26D5D2EADFD; Sun, 10 May 2020 15:42:20 +0000 (UTC) Delivered-To: hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 267A82EADFC; Sun, 10 May 2020 15:42:20 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 49KpGf5MfYz4Kqb; Sun, 10 May 2020 15:42:18 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13:0:0:0:5]) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id 04AFfXoV015861 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 10 May 2020 15:41:36 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: lobo@bsd.com.br Received: from [10.58.0.10] (dadvw [10.58.0.10]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id 04AFfUDm089302 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 10 May 2020 22:41:30 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: Find specific changes between revisions To: Mario Lobo , hackers@freebsd.org, vbox@freebsd.org, "freebsd-emulation@freebsd.org" References: <614e0ff9-1adc-1634-5711-ca032d6260bf@fastmail.com> From: Eugene Grosbein Message-ID: <91d3b015-3708-eacd-3706-5729e0b96e9e@grosbein.net> Date: Sun, 10 May 2020 22:41:24 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_00,LOCAL_FROM, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * -0.0 SPF_PASS SPF: sender matches SPF record * 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 49KpGf5MfYz4Kqb X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=permerror (mx1.freebsd.org: domain of eugen@grosbein.net uses mechanism not recognized by this client) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [-4.00 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[grosbein.net]; SH_EMAIL_DBL_DONT_QUERY_IPS(0.00)[0.5.128.228,0.5.126.35]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_PERMFAIL(0.00)[]; IP_SCORE(-1.90)[ip: (-5.31), ipnet: 2a01:4f8::/29(-2.66), asn: 24940(-1.50), country: DE(-0.02)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; SH_EMAIL_ZRD(0.00)[0.5.128.228,0.5.126.35] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 May 2020 15:42:20 -0000 10.05.2020 5:52, Mario Lobo wrote: > The command: > > svn diff https://svn.freebsd.org/base/stable/11@359971 > https://svn.freebsd.org/base/stable/11@360676 > > yielded a 170 Mbytes file!! > > It will be like looking for a needle in a haystack, in the dark, with just > a hunch of where the needle was dropped. > > Well ... at least I have the haystack. > > Thanks everyone for the tips! You don't really need to study source code to bisect the problem, just use "svnlite update -rZZZZZ" to move your source tree to the middle point between known working and non-working revisions. Then rebuild and reinstall kernel and world, reboot and re-do the test. If it works, you get new (higher) working revision and if not, you get new (lower) non-working one. Repeat until you have only single revision between working and non-working. This procedure takes time and effort but this is not like looking for a needle in a haystack, much easier. From owner-freebsd-hackers@freebsd.org Sun May 10 16:03:30 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 5621E2EB73B for ; Sun, 10 May 2020 16:03:30 +0000 (UTC) (envelope-from debdrup@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 49Kpl61fRLz4LyF for ; Sun, 10 May 2020 16:03:30 +0000 (UTC) (envelope-from debdrup@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 38AB62EB73A; Sun, 10 May 2020 16:03:30 +0000 (UTC) Delivered-To: hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 387092EB739 for ; Sun, 10 May 2020 16:03:30 +0000 (UTC) (envelope-from debdrup@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49Kpl60j0vz4LyD for ; Sun, 10 May 2020 16:03:30 +0000 (UTC) (envelope-from debdrup@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1471) id E636518821; Sun, 10 May 2020 16:03:29 +0000 (UTC) Date: Sun, 10 May 2020 18:03:27 +0200 From: Daniel Ebdrup Jensen To: hackers@freebsd.org Subject: Re: Find specific changes between revisions Message-ID: <20200510160327.r5x5j5mkrrcmmy4k@nerd-thinkpad.local> Mail-Followup-To: Daniel Ebdrup Jensen , hackers@freebsd.org References: <614e0ff9-1adc-1634-5711-ca032d6260bf@fastmail.com> <91d3b015-3708-eacd-3706-5729e0b96e9e@grosbein.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="kaozxhlbd5xwwgfb" Content-Disposition: inline In-Reply-To: <91d3b015-3708-eacd-3706-5729e0b96e9e@grosbein.net> X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 May 2020 16:03:30 -0000 --kaozxhlbd5xwwgfb Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, May 10, 2020 at 10:41:24PM +0700, Eugene Grosbein wrote: >10.05.2020 5:52, Mario Lobo wrote: > >> The command: >> >> svn diff https://svn.freebsd.org/base/stable/11@359971 >> https://svn.freebsd.org/base/stable/11@360676 >> >> yielded a 170 Mbytes file!! >> >> It will be like looking for a needle in a haystack, in the dark, with ju= st >> a hunch of where the needle was dropped. >> >> Well ... at least I have the haystack. >> >> Thanks everyone for the tips! > >You don't really need to study source code to bisect the problem, >just use "svnlite update -rZZZZZ" to move your source tree to the middle p= oint >between known working and non-working revisions. Then rebuild and reinstall >kernel and world, reboot and re-do the test. If it works, you get new (hig= her) >working revision and if not, you get new (lower) non-working one. > >Repeat until you have only single revision between working and non-working. >This procedure takes time and effort but this is not like looking for a ne= edle in a haystack, much easier. >_______________________________________________ >freebsd-hackers@freebsd.org mailing list >https://lists.freebsd.org/mailman/listinfo/freebsd-hackers >To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" If you're going to be doing this kind of rebuilding from revision to revisi= on, I=20 feel obliged to mention that you can put MetaMode [1] to great use. Essentially, it ensures that you only rebuild whatever's changed from one= =20 revision to another, and on the source tree it can make a HUGE difference w= hen=20 jumping small revision amounts (and even if large numbers of revisions are= =20 jumped over, it still has some impact. It's sort of like ccache, except much more efficient. Yours, Daniel Ebdrup Jensen [1]: https://wiki.freebsd.org/MetaMode --kaozxhlbd5xwwgfb Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAEBCgB9FiEEDonNJPbg/JLIMoS6Ps5hSHzN87oFAl64Jc9fFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDBF ODlDRDI0RjZFMEZDOTJDODMyODRCQTNFQ0U2MTQ4N0NDREYzQkEACgkQPs5hSHzN 87qfSQf/T3LeKV3n3YTUYGQV4CesTUJc4kzQqwXSRWF/SChmsm6DZtAq3fH5d39l oIDiSd/UvVoGZR+r3cX/VOtJEMPDFC0oVKH119/ttud0SdedPV0mZETyGEQ3Eo6L 9uFUoFV5niKbhGES/R8fKdzZQPD0BSO2zOljiHs/9++OvZm1RosRHbHJX1i7juy0 +IvEJj8oROSqpNC2uNy6e4KsWSb/EjT7IrBsruc9GtCmsGUJuD89tZx8RBOBaUSW 6IWAfXywHTfoCJyVNHRb7J0gnTpuaNGgJ8Sh7lTjJsXA9gmPINAReg8wtHajAM4N w/2eRw6FKwKxjBDQ3y+Ktr/EjPi8uw== =LW04 -----END PGP SIGNATURE----- --kaozxhlbd5xwwgfb-- From owner-freebsd-hackers@freebsd.org Sun May 10 20:23:33 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 858CC2F2AB2 for ; Sun, 10 May 2020 20:23:33 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-oi1-f175.google.com (mail-oi1-f175.google.com [209.85.167.175]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) 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 49KwW84DcBz4cNR for ; Sun, 10 May 2020 20:23:32 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-oi1-f175.google.com with SMTP id r66so13401124oie.5 for ; Sun, 10 May 2020 13:23:32 -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:reply-to :from:date:message-id:subject:to:cc:content-transfer-encoding; bh=v79G0qrx307wjZqsvS0PSgkMGmY4KJ/6KMlK33C0eaE=; b=hcm7z9PKmgiyMbTLb9HphlGyrx2GzWfGYGPXRHevg89JDfh1dny7fQkqKW2YJYp084 CLg4ld4WeY3Quo3fDYI/R0LrQEqxuxg9VRtk29ad2t/CtZDno3XUJOb61eT/frt2PMeP zOQhiSfxcUzCRKl8Wv/m2rrhUZb4Q7WeOP1WwHWZglKOxVa5Lp2K23x3ivz3xOqILBmZ 5rBNCB1db29nuBDbR2JA+zH//8IK1wyXCVtFiiLQcAUlaKz/mOAVi7HSO3HZH4+nQp8C 4KICI63/wbl18qw5mj2vb5dS3g/kPwsA9gO1EESe6vUQHE/7egeZQvpHruv45j2VGSrn 4xgQ== X-Gm-Message-State: AGi0PubFnG9EkKciWUxcloll8fCszRijdNivN/0dM0MEOMJrHSR1wwA6 yfCTOpe1CRksVZQXDMCdv/Ht/40p X-Google-Smtp-Source: APiQypJtDDM09VO8DQXm47QECoOW1WWUds8H5T6bMxyRWfLJ7J2wDVK5P8GNzSjn3R7zwq+EiDNLDQ== X-Received: by 2002:aca:c68b:: with SMTP id w133mr17843724oif.175.1589142211496; Sun, 10 May 2020 13:23:31 -0700 (PDT) Received: from mail-ot1-f50.google.com (mail-ot1-f50.google.com. [209.85.210.50]) by smtp.gmail.com with ESMTPSA id t13sm2307647ooo.1.2020.05.10.13.23.31 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 10 May 2020 13:23:31 -0700 (PDT) Received: by mail-ot1-f50.google.com with SMTP id j26so5947319ots.0 for ; Sun, 10 May 2020 13:23:31 -0700 (PDT) X-Received: by 2002:a9d:6f16:: with SMTP id n22mr10499372otq.216.1589142210859; Sun, 10 May 2020 13:23:30 -0700 (PDT) MIME-Version: 1.0 References: <695d2c45-9901-3f3e-ec7d-d11b75efa8e6@systella.fr> <95cabd0b-8384-5fa1-6e9a-e5f2e24f1bac@systella.fr> <5c6b3ba1-0683-e42a-ee01-1c698425d733@systella.fr> In-Reply-To: <5c6b3ba1-0683-e42a-ee01-1c698425d733@systella.fr> Reply-To: cem@freebsd.org From: Conrad Meyer Date: Sun, 10 May 2020 13:23:20 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Segfault on some applications using qt5 To: =?UTF-8?Q?BERTRAND_Jo=C3=ABl?= Cc: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 49KwW84DcBz4cNR X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of csecem@gmail.com designates 209.85.167.175 as permitted sender) smtp.mailfrom=csecem@gmail.com X-Spamd-Result: default: False [-2.22 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_REPLYTO(0.00)[cem@freebsd.org]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; REPLYTO_ADDR_EQ_FROM(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; RCPT_COUNT_TWO(0.00)[2]; FORGED_SENDER(0.30)[cem@freebsd.org,csecem@gmail.com]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; TAGGED_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; FROM_NEQ_ENVFROM(0.00)[cem@freebsd.org,csecem@gmail.com]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[175.167.85.209.list.dnswl.org : 127.0.5.0]; IP_SCORE(-0.22)[ip: (-0.26), ipnet: 209.85.128.0/17(-0.39), asn: 15169(-0.43), country: US(-0.05)]; RWL_MAILSPIKE_POSSIBLE(0.00)[175.167.85.209.rep.mailspike.net : 127.0.0.17]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 May 2020 20:23:33 -0000 Sorry, I am afraid I don't have any time to spend on this. On Sun, May 10, 2020 at 12:55 AM BERTRAND Jo=C3=ABl wrote: > > Conrad Meyer a =C3=A9crit : > > Great, thanks! > > > > Hi Conrad, > > Were you able to reproduce these segfaults ? I have tried to solv= e them > without any success. I can also open ssh access on this workstation if > you want. > > Best regards, > > JKB From owner-freebsd-hackers@freebsd.org Sun May 10 22:28:32 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 56ECF2F5CD3; Sun, 10 May 2020 22:28:32 +0000 (UTC) (envelope-from freebsd@sysctl.cz) Received: from wes1-so1.wedos.net (wes1-so1.wedos.net [46.28.106.15]) (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 49KzHM154tz3GRb; Sun, 10 May 2020 22:28:30 +0000 (UTC) (envelope-from freebsd@sysctl.cz) Received: from webmail.wedos.net (wes1-wm3.wedos.net [46.28.106.84]) by wes1-so1.wedos.net (Postfix) with ESMTPSA id 49KzHC2Kwyz2Q4; Mon, 11 May 2020 00:28:23 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 11 May 2020 00:28:23 +0200 From: freebsd@sysctl.cz To: freebsd-hackers@freebsd.org Cc: Freebsd emulation Subject: Debug linux binary with enable linux emulation Message-ID: <24f30eaa0597d79ddadc10d6f993f2a0@sysctl.cz> X-Sender: freebsd@sysctl.cz User-Agent: Roundcube Webmail/1.2.4 X-Rspamd-Queue-Id: 49KzHM154tz3GRb X-Spamd-Bar: +++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd@sysctl.cz has no SPF policy when checking 46.28.106.15) smtp.mailfrom=freebsd@sysctl.cz X-Spamd-Result: default: False [3.93 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; IP_SCORE(1.12)[ipnet: 46.28.104.0/21(1.70), asn: 197019(3.78), country: CZ(0.09)]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[sysctl.cz]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.92)[0.916,0]; RCPT_COUNT_TWO(0.00)[2]; FROM_NO_DN(0.00)[]; NEURAL_SPAM_LONG(1.00)[0.998,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:197019, ipnet:46.28.104.0/21, country:CZ]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 May 2020 22:28:32 -0000 Hi, I tried debug with gdb for linux emulation and have issue with kernel panic. kldload linux64.ko gdb ./Discord or other linux binary Fatal trap 12: page fault while in kernel mode cpuid = 3; apic id = 03 fault virtual address = 0x18 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff82f5b682 stack pointer = 0x28:0xfffffe00691fd980 frame pointer = 0x28:0xfffffe00691fd9e0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 17392 (fish) trap number = 12 panic: page fault cpuid = 3 time = 1589132677 KDB: stack backtrace: #0 0xffffffff80c1d2f7 at kdb_backtrace+0x67 #1 0xffffffff80bd062d at vpanic+0x19d #2 0xffffffff80bd0483 at panic+0x43 #3 0xffffffff810a7dcc at trap_fatal+0x39c #4 0xffffffff810a7e19 at trap_pfault+0x49 #5 0xffffffff810a740f at trap+0x29f #6 0xffffffff81081bdc at calltrap+0x8 #7 0xffffffff82f503d1 at linux_thread_detach+0x21 #8 0xffffffff80be5acf at thread_suspend_check+0x41f #9 0xffffffff80c32ed9 at ast+0x3b9 #10 0xffffffff810850e9 at doreti_ast+0x1f Uptime: 2h56m24s Dumping 1146 out of 8042 MB:..2%..12%..21%..31%..41%..51%..62%..72%..81%..91%---<>--- Copyright (c) 1992-2019 The FreeBSD Project. GNU gdb (GDB) 9.1 [GDB v9.1 for FreeBSD] Copyright (C) 2020 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-portbld-freebsd12.1". Type "show configuration" for configuration details. For bug reporting instructions, please see: . Find the GDB manual and other documentation resources online at: . For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /boot/kernel/kernel... (No debugging symbols found in /boot/kernel/kernel) 0xffffffff80c01eda in sched_switch () (kgdb) (kgdb) (kgdb) bt #0 0xffffffff80c01eda in sched_switch () #1 0xffffffff80bdbfa2 in mi_switch () #2 0xffffffff80c2bb75 in sleepq_catch_signals () #3 0xffffffff80c2be64 in sleepq_timedwait_sig () #4 0xffffffff80bdb9a5 in _sleep () #5 0xffffffff80bf1ee3 in umtxq_sleep () #6 0xffffffff80bf1c90 in do_wait () #7 0xffffffff80bef8fe in __umtx_op_wait_uint_private () #8 0xffffffff810a8984 in amd64_syscall () #9 #10 0x000000080974dedc in ?? () Backtrace stopped: Cannot access memory at address 0x7fffffffddc8 I have now kernel without debug symbols. M. From owner-freebsd-hackers@freebsd.org Mon May 11 02:53:29 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 7FE522D3A7C for ; Mon, 11 May 2020 02:53:29 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-25.consmr.mail.gq1.yahoo.com (sonic312-25.consmr.mail.gq1.yahoo.com [98.137.69.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49L5942fnfz3xkJ for ; Mon, 11 May 2020 02:53:27 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: GEM_aYgVM1kUIyTf_LYoiFGb0Q7rW6OYpsUWyv59NjxsvA.W1mj_sUC6My4Hxor Xw.RK_oOsQKkGfhVtwZT4UPnAONfx8ljF1I4kwjNoPzDe46arN78Q1l35UlrMQbCP.eb7JcER3PV XGYU9jzY7uQrMYb0qOGYvsdv0BhaeTxXOXtgzG20NZWxeIer6reUAFA3G5Pr81RXpZ6h..jLIl9D 2teTg3EQWNMDGp8._cA6ki3jEfys5dIuB57PHbSmJPPSm_AVvWDAIK0ml2mMfRSK6oK.NJ62SWx. sOXmnsK4lNfvTU3bubG9eFWv3wXRW.OhzQvRNu7TUwrcfoKj6Kh6.hkFWUIvm6kN2bAucNSPtz6d on10mk5d9jWx4MY3oicMbQEZEAH4zpzI8ftYWQ5aEnWFNMeTtgGbW45rJiaXpZx.hCBHhCzNxDe0 HdvjJMBbHRHWfqKwKjgGHu97m3MXe_bnq5ef782Gw0P0aMd5RaWSNbNZ5DvA8x3R45O5yM1DlvTi 1_Fpk_GZu.GEi6rxyqB.l_udPOddLljo8MQ9PphkBPP4KLK1nhU4MkRaFOmgOvIGacMz.JpotjdZ mzFfE8QIqCeavOw45n5ZR7ov2C5xihkP20WM.7OD9HszMRVNN362zapGzuFQ0mjRN.7_P0Q_1EOZ x7KNVFniO0NCCT_iToBQ0TABf8fNydPesyVQvmct.b8pLEfrBN5_j97PJIl_thYu8z5Aq8.8ULAS fAUXsLvqv9TfdOrl8wPWYBeNCRB.GT76kR9ddhPaNwsw58V96u2NJCWcRBX8QjsH.lAZ96EFCVCK ImcJWpkADaUSaUqH7ekW.jA3gFEIdCnxKLA4mFN4RKnyg6VvYkBDZQJkSL_U1QprwWfotRFTFWbx e1KEDHUydze5Bugac3l8oOAz4v2XrzdbzxXxEzqcKVLVQvmdjcj9SkCJJ.pMU3w8K5F70Wi7tYlJ xjqAXP0lmwN2hzbwHlM7lY8CDEhZks04ipicvaeEOWar7xW8i9OJihIpimuFO6BRE.c4ldLTlyS_ _3phTkpX13rgAVVcSXIiVFyFM2dvDlCz1lw4O2HsN_2Xt5MLCO_3h2u7yEpxZoLMHQanWY3XdZEY Ytb0Q2PtislE8fnzD6c0W2O8pTGXvHk2iH6Vb431KrjDBTmt3agMXXsAuzib9Xt0Gapyx3QRPskM miyX23sHgbE3SNhPkqnC7aSu8D.2vAd271A19Zc17B7iwJCfGsuy6kFrlCluRNmkGFbvx4Aj8AOc tDmBHl.RsnrsIXl73CxyFhg.Z.g8avkyde6baMwXhDbH_FpeVbn_jw0pYVInPM_5WOikgsCMQtfU 6Fe15UM2xnBz2ZAqDWA7BgLmwTn2u1DCJ9qnBORAty.kJtWNvEprgAVA9DuyvnO0e6b81p8OrFro hy2HOI23hVggrLpumFJkhfrFKJdYbvhwm0vyWFxnfiE6B_TX1i4W5gSLTWzFh Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Mon, 11 May 2020 02:53:26 +0000 Received: by smtp414.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 1e0514e9cf2507050b754f47e602e546; Mon, 11 May 2020 02:53:21 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: svn commit: r360233 - in head: contrib/jemalloc . . . : This partially breaks a 2-socket 32-bit powerpc (old PowerMac G4) based on head -r360311 From: Mark Millard In-Reply-To: Date: Sun, 10 May 2020 19:53:19 -0700 Cc: Brandon Bergren , Justin Hibbits Content-Transfer-Encoding: 7bit Message-Id: References: <8479DD58-44F6-446A-9CA5-D01F0F7C1B38@yahoo.com> <17ACDA02-D7EF-4F26-874A-BB3E935CD072@yahoo.com> <695E6836-F860-4557-B7DE-CC1EDB347F18@yahoo.com> <121B9B09-141B-4DC3-918B-1E7CFB99E779@yahoo.com> <8AAB0462-3FA8-490C-8D8D-7C15B1C9E2DE@yahoo.com> <18E62746-80DB-4195-977D-4FF32D0129EE@yahoo.com> To: "vangyzen@freebsd.org" , svn-src-head@freebsd.org, FreeBSD Current , FreeBSD Hackers , FreeBSD PowerPC ML X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 49L5942fnfz3xkJ X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.50 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCPT_COUNT_SEVEN(0.00)[7]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.00)[ip: (-3.69), ipnet: 98.137.64.0/21(0.83), asn: 36647(0.66), country: US(-0.05)]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[206.69.137.98.list.dnswl.org : 127.0.5.0]; RWL_MAILSPIKE_POSSIBLE(0.00)[206.69.137.98.rep.mailspike.net : 127.0.0.17]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2020 02:53:29 -0000 [A new kind of experiment and partial results.] Given the zero'ed memory page(s) that for some of the example contexts include a page that should not be changing after initialization in my context (jemalloc global variables), I have attempted the following for such examples: A) Run gdb B) Attach to one of the live example processes. C) Check that the page is not zeroed yet. (print/x __je_sz_size2index_tab) D) protect the page containing the start of __je_sz_size2index_tab, using 0x1 as the PROT_READ mask. (print (int)mprotect(ADDRESS,1,0x1)) E) detach. The hope was to discover which of the following was involved: A) user-space code trying to write the page should get a SIGSEGV. In this case I'd likely be able to see what code was attempting the write. B) kernel-code doing something odd to the content or mapping of memory would not (or need not) lead to SIGSEGV. In this case I'd be unlikely to see what code lead to the zeros on the page. So far I've gotten only one failure example, nfsd during its handling of a SIGUSR1. Previous nfs mounts and dismounts worked fine, not asserting, indicating that at the time the page was not zeroed. I got no evidence of SIGSEGV from an attempted user space write to the page. But the nfsd.core shows the page as zeroed and the assert having caused abort(). That suggests the kernel side of things for what leads to the zeros. It turns out that just before the "unregsiteration()" activity is "killchildren()" activity: (gdb) list 971 972 static void 973 nfsd_exit(int status) 974 { 975 killchildren(); 976 unregistration(); 977 exit(status); 978 } (frame #12) used via: (gdb) list cleanup 954 /* 955 * Cleanup master after SIGUSR1. 956 */ 957 static void 958 cleanup(__unused int signo) 959 { 960 nfsd_exit(0); 961 } . . . and (for master): (void)signal(SIGUSR1, cleanup); This suggests the possibility that the zero'd pages could be associated with killing the child processes. (I've had a past aarch64 context where forking had problems with pages that were initially common to parent and child processes. In that context having the processes swap out [not just mostly paged out] and then swap back in was involved in showing the problem. The issue was fixed and was aarch64 specific. But it leaves me willing to consider fork-related memory management as possibly odd in some way for 32-bit powerpc.) Notes . . . Another possible kind of evidence: I've gone far longer with the machine doing just normal background processing with nothing failing on its own. This suggests that the (int)mprotect(ADDRESS,1,0x1) might be changing the context --or just doing the attach and detach in gdb does. I've nothing solid in this area so I'll ignore it, other than this note. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-hackers@freebsd.org Mon May 11 11:57:13 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 029792DF05A; Mon, 11 May 2020 11:57:13 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49LKDR3spgz4S6C; Mon, 11 May 2020 11:57:11 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id 04BBuvdS029967 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 11 May 2020 14:57:00 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 04BBuvdS029967 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id 04BBuuIa029966; Mon, 11 May 2020 14:56:56 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 11 May 2020 14:56:56 +0300 From: Konstantin Belousov To: freebsd@sysctl.cz Cc: freebsd-hackers@freebsd.org, Freebsd emulation Subject: Re: Debug linux binary with enable linux emulation Message-ID: <20200511115656.GF68906@kib.kiev.ua> References: <24f30eaa0597d79ddadc10d6f993f2a0@sysctl.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <24f30eaa0597d79ddadc10d6f993f2a0@sysctl.cz> X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on tom.home X-Rspamd-Queue-Id: 49LKDR3spgz4S6C X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kostikbel@gmail.com) smtp.mailfrom=kostikbel@gmail.com X-Spamd-Result: default: False [-2.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[gmail.com]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all:c]; IP_SCORE_FREEMAIL(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; IP_SCORE(0.00)[ip: (-3.04), ipnet: 2001:470::/32(-4.08), asn: 6939(-3.14), country: US(-0.05)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2020 11:57:13 -0000 On Mon, May 11, 2020 at 12:28:23AM +0200, freebsd@sysctl.cz wrote: > Hi, > I tried debug with gdb for linux emulation > and have issue with kernel panic. > > kldload linux64.ko > gdb ./Discord or other linux binary > > Fatal trap 12: page fault while in kernel mode > cpuid = 3; apic id = 03 > fault virtual address = 0x18 > fault code = supervisor read data, page not present > instruction pointer = 0x20:0xffffffff82f5b682 > stack pointer = 0x28:0xfffffe00691fd980 > frame pointer = 0x28:0xfffffe00691fd9e0 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 17392 (fish) > trap number = 12 > panic: page fault > cpuid = 3 > time = 1589132677 > KDB: stack backtrace: > #0 0xffffffff80c1d2f7 at kdb_backtrace+0x67 > #1 0xffffffff80bd062d at vpanic+0x19d > #2 0xffffffff80bd0483 at panic+0x43 > #3 0xffffffff810a7dcc at trap_fatal+0x39c > #4 0xffffffff810a7e19 at trap_pfault+0x49 > #5 0xffffffff810a740f at trap+0x29f > #6 0xffffffff81081bdc at calltrap+0x8 > #7 0xffffffff82f503d1 at linux_thread_detach+0x21 Show the line number for linux_thread_detach+0x21. Or better, compile with INVARIANTS, it should fire an assertion. Then get a core dump. > #8 0xffffffff80be5acf at thread_suspend_check+0x41f > #9 0xffffffff80c32ed9 at ast+0x3b9 > #10 0xffffffff810850e9 at doreti_ast+0x1f > Uptime: 2h56m24s > Dumping 1146 out of 8042 > MB:..2%..12%..21%..31%..41%..51%..62%..72%..81%..91%---<>--- > Copyright (c) 1992-2019 The FreeBSD Project. > > GNU gdb (GDB) 9.1 [GDB v9.1 for FreeBSD] > Copyright (C) 2020 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. > Type "show copying" and "show warranty" for details. > This GDB was configured as "x86_64-portbld-freebsd12.1". > Type "show configuration" for configuration details. > For bug reporting instructions, please see: > . > Find the GDB manual and other documentation resources online at: > . > > For help, type "help". > Type "apropos word" to search for commands related to "word"... > Reading symbols from /boot/kernel/kernel... > (No debugging symbols found in /boot/kernel/kernel) > 0xffffffff80c01eda in sched_switch () > (kgdb) > (kgdb) > (kgdb) bt > #0 0xffffffff80c01eda in sched_switch () > #1 0xffffffff80bdbfa2 in mi_switch () > #2 0xffffffff80c2bb75 in sleepq_catch_signals () > #3 0xffffffff80c2be64 in sleepq_timedwait_sig () > #4 0xffffffff80bdb9a5 in _sleep () > #5 0xffffffff80bf1ee3 in umtxq_sleep () > #6 0xffffffff80bf1c90 in do_wait () > #7 0xffffffff80bef8fe in __umtx_op_wait_uint_private () > #8 0xffffffff810a8984 in amd64_syscall () > #9 > #10 0x000000080974dedc in ?? () > Backtrace stopped: Cannot access memory at address 0x7fffffffddc8 > > I have now kernel without debug symbols. > > M. > _______________________________________________ > freebsd-emulation@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-emulation > To unsubscribe, send any mail to "freebsd-emulation-unsubscribe@freebsd.org" From owner-freebsd-hackers@freebsd.org Mon May 11 21:05:49 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 7293C2EC82B for ; Mon, 11 May 2020 21:05:49 +0000 (UTC) (envelope-from lobo@bsd.com.br) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 49LYPS6MJ2z4B6M for ; Mon, 11 May 2020 21:05:48 +0000 (UTC) (envelope-from lobo@bsd.com.br) Received: by mailman.nyi.freebsd.org (Postfix) id DA39A2EC829; Mon, 11 May 2020 21:05:48 +0000 (UTC) Delivered-To: hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D9FF22EC828 for ; Mon, 11 May 2020 21:05:48 +0000 (UTC) (envelope-from lobo@bsd.com.br) Received: from mail-il1-x143.google.com (mail-il1-x143.google.com [IPv6:2607:f8b0:4864:20::143]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) 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 49LYPR3hgLz4B6K for ; Mon, 11 May 2020 21:05:46 +0000 (UTC) (envelope-from lobo@bsd.com.br) Received: by mail-il1-x143.google.com with SMTP id c18so10144310ile.5 for ; Mon, 11 May 2020 14:05:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsd.com.br; s=capeta; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=6kRdWZ5OO9COhRq+LekzxQMzLd8hAs18ADtePDqmsmk=; b=TYu0aijYCcPh+L+XzgD7sJzKF9V1K3RdbcIFYU/sOtt/i7fDfkIJlQgI691GK1t7g4 bND/GsNE33rvmquGu1yjlhEHjhDCyTh30Vhhvd7YWBegU5ds/lGb2sGed4S9qtaJzFH6 WU1Bqngh2Jv3JTtrh3kyV0OZs9EnIw9rKoZ9k= 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=6kRdWZ5OO9COhRq+LekzxQMzLd8hAs18ADtePDqmsmk=; b=UCOeEZWdp0zwP7aom/VUUSqAVDJotxN9FyieV8x7MaTwEAdhDPqW50b85l9UAw/fVK m0pSGEOPYEaGlSu81xh3GP4QX1Aj70ezFr+4n07AZtCb1SLS0TkCZJfvkMBazRbSxhQl BpgCD2MD+mQs3ELA/jhs/RMRAflrbWt4JWs8tnFCg89y6szydOhTUPz7aSnitzDURPr/ Cj3Dg6TIIlQXs4EG7QL/+UxDCQj3iaXfbSQyp0lr+t23tG5zcq7ZsX5//5HjnOXIp43q sWj32oK3nubg4HERSYULAKLZzB0BVTcuTMZX0CIV2bJUZG02uGLzl4gzVPpBdsbgjQfv cHig== X-Gm-Message-State: AGi0PuYfFsP7DixxJTkrWU1OD42V6AGXNt/exOTOsAv8VryFQOVy/7RH BrxCY4jzgrDLmUdNZg8ORI/ITQPfoFW4rJFHSCo1FNYz X-Google-Smtp-Source: APiQypLyyppgYdrIHE7Ry3CNUtaWMdimkygJhsnfLZt5x8sleFjrI6W9BrY5poKxE06nAQvi1KsZWmiLfJJifu0Ct3I= X-Received: by 2002:a92:8c0d:: with SMTP id o13mr5475754ild.117.1589231145580; Mon, 11 May 2020 14:05:45 -0700 (PDT) MIME-Version: 1.0 References: <614e0ff9-1adc-1634-5711-ca032d6260bf@fastmail.com> <91d3b015-3708-eacd-3706-5729e0b96e9e@grosbein.net> <20200510160327.r5x5j5mkrrcmmy4k@nerd-thinkpad.local> In-Reply-To: <20200510160327.r5x5j5mkrrcmmy4k@nerd-thinkpad.local> From: Mario Lobo Date: Mon, 11 May 2020 18:05:33 -0300 Message-ID: Subject: Re: Find specific changes between revisions To: hackers@freebsd.org X-Rspamd-Queue-Id: 49LYPR3hgLz4B6K X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsd.com.br header.s=capeta header.b=TYu0aijY; dmarc=none; spf=pass (mx1.freebsd.org: domain of lobo@bsd.com.br designates 2607:f8b0:4864:20::143 as permitted sender) smtp.mailfrom=lobo@bsd.com.br X-Spamd-Result: default: False [-1.61 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.992,0]; R_DKIM_ALLOW(-0.20)[bsd.com.br:s=capeta]; FROM_HAS_DN(0.00)[]; SH_EMAIL_DBL_DONT_QUERY_IPS(0.00)[0.5.128.228,0.5.126.35]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[hackers@freebsd.org]; TO_DN_NONE(0.00)[]; URI_COUNT_ODD(1.00)[15]; RCPT_COUNT_ONE(0.00)[1]; DMARC_NA(0.00)[bsd.com.br]; DKIM_TRACE(0.00)[bsd.com.br:+]; RCVD_IN_DNSWL_NONE(0.00)[3.4.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; NEURAL_HAM_LONG(-1.00)[-0.998,0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; IP_SCORE(-0.12)[ip: (0.18), ipnet: 2607:f8b0::/32(-0.33), asn: 15169(-0.43), country: US(-0.05)]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; SH_EMAIL_ZRD(0.00)[0.5.126.35,0.5.128.228] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2020 21:05:49 -0000 On Sun, May 10, 2020 at 1:03 PM Daniel Ebdrup Jensen wrote: > On Sun, May 10, 2020 at 10:41:24PM +0700, Eugene Grosbein wrote: > >10.05.2020 5:52, Mario Lobo wrote: > > > >> The command: > >> > >> svn diff https://svn.freebsd.org/base/stable/11@359971 > >> https://svn.freebsd.org/base/stable/11@360676 > >> > >> yielded a 170 Mbytes file!! > >> > >> It will be like looking for a needle in a haystack, in the dark, with > just > >> a hunch of where the needle was dropped. > >> > >> Well ... at least I have the haystack. > >> > >> Thanks everyone for the tips! > > > >You don't really need to study source code to bisect the problem, > >just use "svnlite update -rZZZZZ" to move your source tree to the middle > point > >between known working and non-working revisions. Then rebuild and > reinstall > >kernel and world, reboot and re-do the test. If it works, you get new > (higher) > >working revision and if not, you get new (lower) non-working one. > > > >Repeat until you have only single revision between working and > non-working. > >This procedure takes time and effort but this is not like looking for a > needle in a haystack, much easier. > >_______________________________________________ > >freebsd-hackers@freebsd.org mailing list > >https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > >To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org > " > > If you're going to be doing this kind of rebuilding from revision to > revision, I > feel obliged to mention that you can put MetaMode [1] to great use. > > Essentially, it ensures that you only rebuild whatever's changed from one > revision to another, and on the source tree it can make a HUGE difference > when > jumping small revision amounts (and even if large numbers of revisions are > jumped over, it still has some impact. > It's sort of like ccache, except much more efficient. > > Yours, > Daniel Ebdrup Jensen > > [1]: https://wiki.freebsd.org/MetaMode > Thanks mates. I've been using meta mode for a while. I'll follow the svn up -rNNNNNN procedure. -- Mario Lobo http://www.mallavoodoo.com.br FreeBSD since version 2.2.8 [not Pro-Audio.... YET!!] From owner-freebsd-hackers@freebsd.org Mon May 11 22:49:34 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 6D6B52D97E4; Mon, 11 May 2020 22:49:34 +0000 (UTC) (envelope-from freebsd@sysctl.cz) Received: from wes1-so1.wedos.net (wes1-so1.wedos.net [46.28.106.43]) (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 49Lbj920Mkz4L3J; Mon, 11 May 2020 22:49:32 +0000 (UTC) (envelope-from freebsd@sysctl.cz) Received: from webmail.wedos.net (wes1-wm3.wedos.net [46.28.106.84]) by wes1-so1.wedos.net (Postfix) with ESMTPSA id 49Lbj14r8rzgH; Tue, 12 May 2020 00:49:25 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 12 May 2020 00:49:25 +0200 From: freebsd@sysctl.cz To: Konstantin Belousov Cc: freebsd-hackers@freebsd.org, Freebsd emulation , owner-freebsd-hackers@freebsd.org Subject: Re: Debug linux binary with enable linux emulation In-Reply-To: <20200511115656.GF68906@kib.kiev.ua> References: <24f30eaa0597d79ddadc10d6f993f2a0@sysctl.cz> <20200511115656.GF68906@kib.kiev.ua> Message-ID: <67eed7f18b68f67ff04f628c4c367535@sysctl.cz> X-Sender: freebsd@sysctl.cz User-Agent: Roundcube Webmail/1.2.4 X-Rspamd-Queue-Id: 49Lbj920Mkz4L3J X-Spamd-Bar: +++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd@sysctl.cz has no SPF policy when checking 46.28.106.43) smtp.mailfrom=freebsd@sysctl.cz X-Spamd-Result: default: False [4.00 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; IP_SCORE(1.10)[ipnet: 46.28.104.0/21(1.64), asn: 197019(3.78), country: CZ(0.09)]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[sysctl.cz]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(1.00)[0.998,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(1.00)[0.998,0]; FROM_NO_DN(0.00)[]; R_SPF_NA(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:197019, ipnet:46.28.104.0/21, country:CZ]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2020 22:49:34 -0000 Dne 2020-05-11 13:56, Konstantin Belousov napsal: > On Mon, May 11, 2020 at 12:28:23AM +0200, freebsd@sysctl.cz wrote: >> Hi, >> I tried debug with gdb for linux emulation >> and have issue with kernel panic. >> >> kldload linux64.ko >> gdb ./Discord or other linux binary >> >> Fatal trap 12: page fault while in kernel mode >> cpuid = 3; apic id = 03 >> fault virtual address = 0x18 >> fault code = supervisor read data, page not present >> instruction pointer = 0x20:0xffffffff82f5b682 >> stack pointer = 0x28:0xfffffe00691fd980 >> frame pointer = 0x28:0xfffffe00691fd9e0 >> code segment = base 0x0, limit 0xfffff, type 0x1b >> = DPL 0, pres 1, long 1, def32 0, gran 1 >> processor eflags = interrupt enabled, resume, IOPL = 0 >> current process = 17392 (fish) >> trap number = 12 >> panic: page fault >> cpuid = 3 >> time = 1589132677 >> KDB: stack backtrace: >> #0 0xffffffff80c1d2f7 at kdb_backtrace+0x67 >> #1 0xffffffff80bd062d at vpanic+0x19d >> #2 0xffffffff80bd0483 at panic+0x43 >> #3 0xffffffff810a7dcc at trap_fatal+0x39c >> #4 0xffffffff810a7e19 at trap_pfault+0x49 >> #5 0xffffffff810a740f at trap+0x29f >> #6 0xffffffff81081bdc at calltrap+0x8 >> #7 0xffffffff82f503d1 at linux_thread_detach+0x21 > Show the line number for linux_thread_detach+0x21. > Or better, compile with INVARIANTS, it should fire an assertion. > Then get a core dump. > >> #8 0xffffffff80be5acf at thread_suspend_check+0x41f >> #9 0xffffffff80c32ed9 at ast+0x3b9 >> #10 0xffffffff810850e9 at doreti_ast+0x1f >> Uptime: 2h56m24s >> Dumping 1146 out of 8042 >> MB:..2%..12%..21%..31%..41%..51%..62%..72%..81%..91%---<>--- >> Copyright (c) 1992-2019 The FreeBSD Project. >> >> GNU gdb (GDB) 9.1 [GDB v9.1 for FreeBSD] >> Copyright (C) 2020 Free Software Foundation, Inc. >> License GPLv3+: GNU GPL version 3 or later >> >> This is free software: you are free to change and redistribute it. >> There is NO WARRANTY, to the extent permitted by law. >> Type "show copying" and "show warranty" for details. >> This GDB was configured as "x86_64-portbld-freebsd12.1". >> Type "show configuration" for configuration details. >> For bug reporting instructions, please see: >> . >> Find the GDB manual and other documentation resources online at: >> . >> >> For help, type "help". >> Type "apropos word" to search for commands related to "word"... >> Reading symbols from /boot/kernel/kernel... >> (No debugging symbols found in /boot/kernel/kernel) >> 0xffffffff80c01eda in sched_switch () >> (kgdb) >> (kgdb) >> (kgdb) bt >> #0 0xffffffff80c01eda in sched_switch () >> #1 0xffffffff80bdbfa2 in mi_switch () >> #2 0xffffffff80c2bb75 in sleepq_catch_signals () >> #3 0xffffffff80c2be64 in sleepq_timedwait_sig () >> #4 0xffffffff80bdb9a5 in _sleep () >> #5 0xffffffff80bf1ee3 in umtxq_sleep () >> #6 0xffffffff80bf1c90 in do_wait () >> #7 0xffffffff80bef8fe in __umtx_op_wait_uint_private () >> #8 0xffffffff810a8984 in amd64_syscall () >> #9 >> #10 0x000000080974dedc in ?? () >> Backtrace stopped: Cannot access memory at address 0x7fffffffddc8 >> >> I have now kernel without debug symbols. >> >> M. >> _______________________________________________ >> freebsd-emulation@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-emulation >> To unsubscribe, send any mail to >> "freebsd-emulation-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to > "freebsd-hackers-unsubscribe@freebsd.org" Hi konstantin, I have good news, now we can look detail (kgdb) bt #0 __curthread () at /usr/src/sys/amd64/include/pcpu.h:234 #1 doadump (textdump=) at /usr/src/sys/kern/kern_shutdown.c:371 #2 0xffffffff80bd0228 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:451 #3 0xffffffff80bd0689 in vpanic (fmt=, ap=) at /usr/src/sys/kern/kern_shutdown.c:877 #4 0xffffffff80bd0483 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:804 #5 0xffffffff810a7dcc in trap_fatal (frame=0xfffffe00634e58c0, eva=24) at /usr/src/sys/amd64/amd64/trap.c:943 #6 0xffffffff810a7e19 in trap_pfault (frame=0xfffffe00634e58c0, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:767 #7 0xffffffff810a740f in trap (frame=0xfffffe00634e58c0) at /usr/src/sys/amd64/amd64/trap.c:443 #8 #9 release_futexes (td=, em=0x0) at /usr/src/sys/compat/linux/linux_futex.c:1283 #10 0xffffffff82f503d1 in linux_thread_detach (td=0xfffff8014bd935e0) at /usr/src/sys/compat/linux/linux_fork.c:466 #11 0xffffffff80be5acf in thread_suspend_check (return_instead=0) at /usr/src/sys/kern/kern_thread.c:1010 #12 0xffffffff80c32ed9 in ast (framep=0xfffffe00634e5ac0) at /usr/src/sys/kern/subr_trap.c:342 #13 0xffffffff810850e9 in doreti_ast () at /usr/src/sys/amd64/amd64/exception.S:1149 #14 0x0000000800bb7008 in ?? () #15 0x000000000000000f in ?? () #16 0x0000000000000000 in ?? () (kgdb) list 0xffffffff82f503d1 Function "0xffffffff82f503d1" not defined. (kgdb) list *0xffffffff82f503d1 0xffffffff82f503d1 is in linux_thread_detach (/usr/src/sys/compat/linux/linux_fork.c:468). warning: Source file is more recent than executable. 463 464 LINUX_CTR1(thread_detach, "thread(%d)", em->em_tid); 465 466 release_futexes(td, em); 467 468 child_clear_tid = em->child_clear_tid; 469 470 if (child_clear_tid != NULL) { 471 472 LINUX_CTR2(thread_detach, "thread(%d) %p", (kgdb) From owner-freebsd-hackers@freebsd.org Tue May 12 17:30:08 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 0BA112F55F1; Tue, 12 May 2020 17:30:08 +0000 (UTC) (envelope-from freebsd@sysctl.cz) Received: from wes1-so1.wedos.net (wes1-so1.wedos.net [46.28.106.43]) (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 49M4Z64pnBz4XJH; Tue, 12 May 2020 17:30:06 +0000 (UTC) (envelope-from freebsd@sysctl.cz) Received: from webmail.wedos.net (wes1-wm3.wedos.net [46.28.106.84]) by wes1-so1.wedos.net (Postfix) with ESMTPSA id 49M4Z36VpMz8nJ; Tue, 12 May 2020 19:30:03 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 12 May 2020 19:30:03 +0200 From: freebsd@sysctl.cz To: Konstantin Belousov Cc: freebsd-hackers@freebsd.org, Freebsd emulation , owner-freebsd-hackers@freebsd.org Subject: Re: Debug linux binary with enable linux emulation In-Reply-To: <67eed7f18b68f67ff04f628c4c367535@sysctl.cz> References: <24f30eaa0597d79ddadc10d6f993f2a0@sysctl.cz> <20200511115656.GF68906@kib.kiev.ua> <67eed7f18b68f67ff04f628c4c367535@sysctl.cz> Message-ID: <8599c3e63190d7b69c9cc7afde61caf4@sysctl.cz> X-Sender: freebsd@sysctl.cz User-Agent: Roundcube Webmail/1.2.4 X-Rspamd-Queue-Id: 49M4Z64pnBz4XJH X-Spamd-Bar: +++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd@sysctl.cz has no SPF policy when checking 46.28.106.43) smtp.mailfrom=freebsd@sysctl.cz X-Spamd-Result: default: False [3.98 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; IP_SCORE(1.09)[ipnet: 46.28.104.0/21(1.58), asn: 197019(3.77), country: CZ(0.09)]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[sysctl.cz]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(1.00)[0.996,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(1.00)[1.000,0]; FROM_NO_DN(0.00)[]; R_SPF_NA(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:197019, ipnet:46.28.104.0/21, country:CZ]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2020 17:30:08 -0000 Dne 2020-05-12 00:49, freebsd@sysctl.cz napsal: > Dne 2020-05-11 13:56, Konstantin Belousov napsal: >> On Mon, May 11, 2020 at 12:28:23AM +0200, freebsd@sysctl.cz wrote: >>> Hi, >>> I tried debug with gdb for linux emulation >>> and have issue with kernel panic. >>> >>> kldload linux64.ko >>> gdb ./Discord or other linux binary >>> >>> Fatal trap 12: page fault while in kernel mode >>> cpuid = 3; apic id = 03 >>> fault virtual address = 0x18 >>> fault code = supervisor read data, page not present >>> instruction pointer = 0x20:0xffffffff82f5b682 >>> stack pointer = 0x28:0xfffffe00691fd980 >>> frame pointer = 0x28:0xfffffe00691fd9e0 >>> code segment = base 0x0, limit 0xfffff, type 0x1b >>> = DPL 0, pres 1, long 1, def32 0, gran 1 >>> processor eflags = interrupt enabled, resume, IOPL = 0 >>> current process = 17392 (fish) >>> trap number = 12 >>> panic: page fault >>> cpuid = 3 >>> time = 1589132677 >>> KDB: stack backtrace: >>> #0 0xffffffff80c1d2f7 at kdb_backtrace+0x67 >>> #1 0xffffffff80bd062d at vpanic+0x19d >>> #2 0xffffffff80bd0483 at panic+0x43 >>> #3 0xffffffff810a7dcc at trap_fatal+0x39c >>> #4 0xffffffff810a7e19 at trap_pfault+0x49 >>> #5 0xffffffff810a740f at trap+0x29f >>> #6 0xffffffff81081bdc at calltrap+0x8 >>> #7 0xffffffff82f503d1 at linux_thread_detach+0x21 >> Show the line number for linux_thread_detach+0x21. >> Or better, compile with INVARIANTS, it should fire an assertion. >> Then get a core dump. >> >>> #8 0xffffffff80be5acf at thread_suspend_check+0x41f >>> #9 0xffffffff80c32ed9 at ast+0x3b9 >>> #10 0xffffffff810850e9 at doreti_ast+0x1f >>> Uptime: 2h56m24s >>> Dumping 1146 out of 8042 >>> MB:..2%..12%..21%..31%..41%..51%..62%..72%..81%..91%---<>--- >>> Copyright (c) 1992-2019 The FreeBSD Project. >>> >>> GNU gdb (GDB) 9.1 [GDB v9.1 for FreeBSD] >>> Copyright (C) 2020 Free Software Foundation, Inc. >>> License GPLv3+: GNU GPL version 3 or later >>> >>> This is free software: you are free to change and redistribute it. >>> There is NO WARRANTY, to the extent permitted by law. >>> Type "show copying" and "show warranty" for details. >>> This GDB was configured as "x86_64-portbld-freebsd12.1". >>> Type "show configuration" for configuration details. >>> For bug reporting instructions, please see: >>> . >>> Find the GDB manual and other documentation resources online at: >>> . >>> >>> For help, type "help". >>> Type "apropos word" to search for commands related to "word"... >>> Reading symbols from /boot/kernel/kernel... >>> (No debugging symbols found in /boot/kernel/kernel) >>> 0xffffffff80c01eda in sched_switch () >>> (kgdb) >>> (kgdb) >>> (kgdb) bt >>> #0 0xffffffff80c01eda in sched_switch () >>> #1 0xffffffff80bdbfa2 in mi_switch () >>> #2 0xffffffff80c2bb75 in sleepq_catch_signals () >>> #3 0xffffffff80c2be64 in sleepq_timedwait_sig () >>> #4 0xffffffff80bdb9a5 in _sleep () >>> #5 0xffffffff80bf1ee3 in umtxq_sleep () >>> #6 0xffffffff80bf1c90 in do_wait () >>> #7 0xffffffff80bef8fe in __umtx_op_wait_uint_private () >>> #8 0xffffffff810a8984 in amd64_syscall () >>> #9 >>> #10 0x000000080974dedc in ?? () >>> Backtrace stopped: Cannot access memory at address 0x7fffffffddc8 >>> >>> I have now kernel without debug symbols. >>> >>> M. >>> _______________________________________________ >>> freebsd-emulation@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-emulation >>> To unsubscribe, send any mail to >>> "freebsd-emulation-unsubscribe@freebsd.org" >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to >> "freebsd-hackers-unsubscribe@freebsd.org" > > > > Hi konstantin, > I have good news, now we can look detail > > (kgdb) bt > #0 __curthread () at /usr/src/sys/amd64/include/pcpu.h:234 > #1 doadump (textdump=) at > /usr/src/sys/kern/kern_shutdown.c:371 > #2 0xffffffff80bd0228 in kern_reboot (howto=260) at > /usr/src/sys/kern/kern_shutdown.c:451 > #3 0xffffffff80bd0689 in vpanic (fmt=, ap= out>) at /usr/src/sys/kern/kern_shutdown.c:877 > #4 0xffffffff80bd0483 in panic (fmt=) at > /usr/src/sys/kern/kern_shutdown.c:804 > #5 0xffffffff810a7dcc in trap_fatal (frame=0xfffffe00634e58c0, > eva=24) at /usr/src/sys/amd64/amd64/trap.c:943 > #6 0xffffffff810a7e19 in trap_pfault (frame=0xfffffe00634e58c0, > usermode=0) at /usr/src/sys/amd64/amd64/trap.c:767 > #7 0xffffffff810a740f in trap (frame=0xfffffe00634e58c0) at > /usr/src/sys/amd64/amd64/trap.c:443 > #8 > #9 release_futexes (td=, em=0x0) at > /usr/src/sys/compat/linux/linux_futex.c:1283 > #10 0xffffffff82f503d1 in linux_thread_detach (td=0xfffff8014bd935e0) > at /usr/src/sys/compat/linux/linux_fork.c:466 > #11 0xffffffff80be5acf in thread_suspend_check (return_instead=0) at > /usr/src/sys/kern/kern_thread.c:1010 > #12 0xffffffff80c32ed9 in ast (framep=0xfffffe00634e5ac0) at > /usr/src/sys/kern/subr_trap.c:342 > #13 0xffffffff810850e9 in doreti_ast () at > /usr/src/sys/amd64/amd64/exception.S:1149 > #14 0x0000000800bb7008 in ?? () > #15 0x000000000000000f in ?? () > #16 0x0000000000000000 in ?? () > (kgdb) list 0xffffffff82f503d1 > Function "0xffffffff82f503d1" not defined. > (kgdb) list *0xffffffff82f503d1 > 0xffffffff82f503d1 is in linux_thread_detach > (/usr/src/sys/compat/linux/linux_fork.c:468). > warning: Source file is more recent than executable. > 463 > 464 LINUX_CTR1(thread_detach, "thread(%d)", em->em_tid); > 465 > 466 release_futexes(td, em); > 467 > 468 child_clear_tid = em->child_clear_tid; > 469 > 470 if (child_clear_tid != NULL) { > 471 > 472 LINUX_CTR2(thread_detach, "thread(%d) %p", > (kgdb) > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to > "freebsd-hackers-unsubscribe@freebsd.org" Hi Konstantin, do you have any idea with debug this kernel panic ? M. From owner-freebsd-hackers@freebsd.org Tue May 12 17:49:47 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 15BC42F5F1C; Tue, 12 May 2020 17:49:47 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49M50m5QQ8z4YhQ; Tue, 12 May 2020 17:49:44 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id 04CHnZgS058368 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 12 May 2020 20:49:38 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 04CHnZgS058368 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id 04CHnZx1058367; Tue, 12 May 2020 20:49:35 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 12 May 2020 20:49:35 +0300 From: Konstantin Belousov To: freebsd@sysctl.cz Cc: freebsd-hackers@freebsd.org, Freebsd emulation , owner-freebsd-hackers@freebsd.org Subject: Re: Debug linux binary with enable linux emulation Message-ID: <20200512174935.GK68906@kib.kiev.ua> References: <24f30eaa0597d79ddadc10d6f993f2a0@sysctl.cz> <20200511115656.GF68906@kib.kiev.ua> <67eed7f18b68f67ff04f628c4c367535@sysctl.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <67eed7f18b68f67ff04f628c4c367535@sysctl.cz> X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on tom.home X-Rspamd-Queue-Id: 49M50m5QQ8z4YhQ X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kostikbel@gmail.com) smtp.mailfrom=kostikbel@gmail.com X-Spamd-Result: default: False [-2.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; FREEMAIL_FROM(0.00)[gmail.com]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all:c]; IP_SCORE_FREEMAIL(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; IP_SCORE(0.00)[ip: (-3.08), ipnet: 2001:470::/32(-4.09), asn: 6939(-3.15), country: US(-0.05)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2020 17:49:47 -0000 On Tue, May 12, 2020 at 12:49:25AM +0200, freebsd@sysctl.cz wrote: > Dne 2020-05-11 13:56, Konstantin Belousov napsal: > > On Mon, May 11, 2020 at 12:28:23AM +0200, freebsd@sysctl.cz wrote: > > > Hi, > > > I tried debug with gdb for linux emulation > > > and have issue with kernel panic. > > > > > > kldload linux64.ko > > > gdb ./Discord or other linux binary > > > > > > Fatal trap 12: page fault while in kernel mode > > > cpuid = 3; apic id = 03 > > > fault virtual address = 0x18 > > > fault code = supervisor read data, page not present > > > instruction pointer = 0x20:0xffffffff82f5b682 > > > stack pointer = 0x28:0xfffffe00691fd980 > > > frame pointer = 0x28:0xfffffe00691fd9e0 > > > code segment = base 0x0, limit 0xfffff, type 0x1b > > > = DPL 0, pres 1, long 1, def32 0, gran 1 > > > processor eflags = interrupt enabled, resume, IOPL = 0 > > > current process = 17392 (fish) > > > trap number = 12 > > > panic: page fault > > > cpuid = 3 > > > time = 1589132677 > > > KDB: stack backtrace: > > > #0 0xffffffff80c1d2f7 at kdb_backtrace+0x67 > > > #1 0xffffffff80bd062d at vpanic+0x19d > > > #2 0xffffffff80bd0483 at panic+0x43 > > > #3 0xffffffff810a7dcc at trap_fatal+0x39c > > > #4 0xffffffff810a7e19 at trap_pfault+0x49 > > > #5 0xffffffff810a740f at trap+0x29f > > > #6 0xffffffff81081bdc at calltrap+0x8 > > > #7 0xffffffff82f503d1 at linux_thread_detach+0x21 > > Show the line number for linux_thread_detach+0x21. > > Or better, compile with INVARIANTS, it should fire an assertion. > > Then get a core dump. > > > > > #8 0xffffffff80be5acf at thread_suspend_check+0x41f > > > #9 0xffffffff80c32ed9 at ast+0x3b9 > > > #10 0xffffffff810850e9 at doreti_ast+0x1f > > > Uptime: 2h56m24s > > > Dumping 1146 out of 8042 > > > MB:..2%..12%..21%..31%..41%..51%..62%..72%..81%..91%---<>--- > > > Copyright (c) 1992-2019 The FreeBSD Project. > > > > > > GNU gdb (GDB) 9.1 [GDB v9.1 for FreeBSD] > > > Copyright (C) 2020 Free Software Foundation, Inc. > > > License GPLv3+: GNU GPL version 3 or later > > > > > > This is free software: you are free to change and redistribute it. > > > There is NO WARRANTY, to the extent permitted by law. > > > Type "show copying" and "show warranty" for details. > > > This GDB was configured as "x86_64-portbld-freebsd12.1". > > > Type "show configuration" for configuration details. > > > For bug reporting instructions, please see: > > > . > > > Find the GDB manual and other documentation resources online at: > > > . > > > > > > For help, type "help". > > > Type "apropos word" to search for commands related to "word"... > > > Reading symbols from /boot/kernel/kernel... > > > (No debugging symbols found in /boot/kernel/kernel) > > > 0xffffffff80c01eda in sched_switch () > > > (kgdb) > > > (kgdb) > > > (kgdb) bt > > > #0 0xffffffff80c01eda in sched_switch () > > > #1 0xffffffff80bdbfa2 in mi_switch () > > > #2 0xffffffff80c2bb75 in sleepq_catch_signals () > > > #3 0xffffffff80c2be64 in sleepq_timedwait_sig () > > > #4 0xffffffff80bdb9a5 in _sleep () > > > #5 0xffffffff80bf1ee3 in umtxq_sleep () > > > #6 0xffffffff80bf1c90 in do_wait () > > > #7 0xffffffff80bef8fe in __umtx_op_wait_uint_private () > > > #8 0xffffffff810a8984 in amd64_syscall () > > > #9 > > > #10 0x000000080974dedc in ?? () > > > Backtrace stopped: Cannot access memory at address 0x7fffffffddc8 > > > > > > I have now kernel without debug symbols. > > > > > > M. > > > _______________________________________________ > > > freebsd-emulation@freebsd.org mailing list > > > https://lists.freebsd.org/mailman/listinfo/freebsd-emulation > > > To unsubscribe, send any mail to > > > "freebsd-emulation-unsubscribe@freebsd.org" > > _______________________________________________ > > freebsd-hackers@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > To unsubscribe, send any mail to > > "freebsd-hackers-unsubscribe@freebsd.org" > > > > Hi konstantin, > I have good news, now we can look detail > > (kgdb) bt > #0 __curthread () at /usr/src/sys/amd64/include/pcpu.h:234 > #1 doadump (textdump=) at > /usr/src/sys/kern/kern_shutdown.c:371 > #2 0xffffffff80bd0228 in kern_reboot (howto=260) at > /usr/src/sys/kern/kern_shutdown.c:451 > #3 0xffffffff80bd0689 in vpanic (fmt=, ap=) > at /usr/src/sys/kern/kern_shutdown.c:877 > #4 0xffffffff80bd0483 in panic (fmt=) at > /usr/src/sys/kern/kern_shutdown.c:804 > #5 0xffffffff810a7dcc in trap_fatal (frame=0xfffffe00634e58c0, eva=24) at > /usr/src/sys/amd64/amd64/trap.c:943 > #6 0xffffffff810a7e19 in trap_pfault (frame=0xfffffe00634e58c0, usermode=0) > at /usr/src/sys/amd64/amd64/trap.c:767 > #7 0xffffffff810a740f in trap (frame=0xfffffe00634e58c0) at > /usr/src/sys/amd64/amd64/trap.c:443 > #8 > #9 release_futexes (td=, em=0x0) at > /usr/src/sys/compat/linux/linux_futex.c:1283 > #10 0xffffffff82f503d1 in linux_thread_detach (td=0xfffff8014bd935e0) at > /usr/src/sys/compat/linux/linux_fork.c:466 > #11 0xffffffff80be5acf in thread_suspend_check (return_instead=0) at > /usr/src/sys/kern/kern_thread.c:1010 > #12 0xffffffff80c32ed9 in ast (framep=0xfffffe00634e5ac0) at > /usr/src/sys/kern/subr_trap.c:342 > #13 0xffffffff810850e9 in doreti_ast () at > /usr/src/sys/amd64/amd64/exception.S:1149 > #14 0x0000000800bb7008 in ?? () > #15 0x000000000000000f in ?? () > #16 0x0000000000000000 in ?? () > (kgdb) list 0xffffffff82f503d1 > Function "0xffffffff82f503d1" not defined. > (kgdb) list *0xffffffff82f503d1 > 0xffffffff82f503d1 is in linux_thread_detach > (/usr/src/sys/compat/linux/linux_fork.c:468). > warning: Source file is more recent than executable. This indicates that your source potentially does not match the kernel. And indeed as seen below, if panic occured on line 468, then it should be due to em dereference, which should be 0. But then, release_futexes() alse dereference em and should cause the same trap earlier. > 463 > 464 LINUX_CTR1(thread_detach, "thread(%d)", em->em_tid); > 465 > 466 release_futexes(td, em); > 467 > 468 child_clear_tid = em->child_clear_tid; > 469 > 470 if (child_clear_tid != NULL) { > 471 > 472 LINUX_CTR2(thread_detach, "thread(%d) %p", > (kgdb) So you did not recompiled with INVARIANTS ? It might be easier if you provide me with a self-contained tarball of small linux binary and all required libraries which reproduce the panic. If not, ensure that the kernel binary is consistent with the sources, that INVARIANTS are enabled, and provide backtraces from gdb for all threads of the paniced process. From owner-freebsd-hackers@freebsd.org Wed May 13 04:52:15 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 173C72E701E for ; Wed, 13 May 2020 04:52:15 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-21.consmr.mail.gq1.yahoo.com (sonic306-21.consmr.mail.gq1.yahoo.com [98.137.68.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49MMj94FVbz4VB2 for ; Wed, 13 May 2020 04:52:13 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: hxTqXNoVM1krm1NdDyZZ5_3FVc.XfgWwVGVJChm5FDiLq78IW._fK0th4eou6bD C_sOD87eZ8lB9WxU5zMAC7Ib20OlNIX4OL0rUy0iDBYhLFyhSWQ_NCIwSUX9rWUloiLUw.otrXAY vur3B0W59dLxVCWw3JHHANWx9lr2RrpgnDWNWLzNwWJ3uOI1yU5r__vW7Hk1J4DER20UwUatIqFc 1OrlQgiHHn2RfY8v6EIgakn4w8lNc1ALP7MCYBikUyDeabWfXaAczmOjsKdAGFz8y0t8X3yFoFbt K1unfDk_oxmk3RR6it7hJv2lVi5vxv12sxgMYMtBLaMFAJeohreEifp.fPrnhOiLVncqMhe7uBfj O5WofNmJt3Ziw6YHx35ID7qA8sPlU3ybxFaOKetRvupxsm..eYw0fQCTZIw8TskhinvHnKoGYh65 .sCktndbEbgb7s9W74N9GxUoAq22HJfyUnRMZ1KwR1779vbgJdyi2ZC3fr1tjOIyUYFZ0Agu98kg Nqtjd9lVTW8r2YH5f3FDY9fk8eytxbot_PRGRNTIg8oEPgiOU8g8RXBBJGcKbvM06LDFYBzIp26K HmO.PukWZii2LWUMEcluMrUVIeIUzyiZsSAAAy7AE.2Jr81tEfFe9d9nByF9RkQxPjjrMh6P9Idp Ks2ypfMnemHfjvwlQCMXgd9AH6dEPt0OigpFHh.RwP.yr4dk4xKiPmrtWJEaqNGU_KzRSzfsMlqs DjpjnvcJOlJ1qmL_agoI2vEmmftvG0Nm7ba8fHO3zB25s4YptFRwIT.zxG6u.sYGLbQ6nt.f7NQG BcEIJFiODbB1i7OeYI0Ycjv4Sdai.RNTsCLpCH_xP3_KpozdQCCFyCRdIkAqvv7MC6y4uC8tTIOL FmX7mI5BTb2tYQWZmvxLDLPf2QiTaOVSxNT08ZtcfmE7vGqM16k9.yHHoEEs04Vvmexq4VyOe802 z9H5Kv3w2TJ9_O6jcqrtvaHUrVLeckceTFsAvKG1EnPxp7rqQBoi3YQ4sl4bQbzmK6oasZL8x39X o00IHDHmSIh9AytfQEEYFW_Y9f5Vj8QtHMgK.mxlsbr1rn7ROb6ODpTWlt1WfPPSdjyGHTwBi9vz ZbYMOBYmOsWYRDlvlPqldOPD9jyaFfWqVjD2CwDm819GrCPHNUoaIi5wBljd2iBgLhqkARRwZ.uN VdYQ4fzuAupTQL8vsabWhs.XDOZHVinXrkV2ZoF797d1cdTPV6KwbIYsvN0yWqU2KHTwnBozqLdF TCkggOM7q55tN12BAhS9KRI6JS.F8HQx_cYO10Lgfh2bJpLLEZLIm_.04HGUYraB.eGQwapP4jWp VBipvEN4jfkDYSBBZnVNKV2CQpS0bVNzunzTsw_35z5poEW9LEDrThIWHdAeXpHLZ05LM7DbHyhk i42GiepvWtj.IrrYNTKN5jDkTYBLQFQ-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Wed, 13 May 2020 04:52:10 +0000 Received: by smtp422.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 43ddc5f4b8c93e8a5b6a17dbda3e0423; Wed, 13 May 2020 04:52:09 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: svn commit: r360233 - in head: contrib/jemalloc . . . : This partially breaks a 2-socket 32-bit powerpc (old PowerMac G4) based on head -r360311 From: Mark Millard In-Reply-To: Date: Tue, 12 May 2020 21:52:06 -0700 Cc: Brandon Bergren , Justin Hibbits Content-Transfer-Encoding: quoted-printable Message-Id: <9562EEE4-62EF-4164-91C0-948CC0432984@yahoo.com> References: <8479DD58-44F6-446A-9CA5-D01F0F7C1B38@yahoo.com> <17ACDA02-D7EF-4F26-874A-BB3E935CD072@yahoo.com> <695E6836-F860-4557-B7DE-CC1EDB347F18@yahoo.com> <121B9B09-141B-4DC3-918B-1E7CFB99E779@yahoo.com> <8AAB0462-3FA8-490C-8D8D-7C15B1C9E2DE@yahoo.com> <18E62746-80DB-4195-977D-4FF32D0129EE@yahoo.com> To: "vangyzen@freebsd.org" , svn-src-head@freebsd.org, FreeBSD Current , FreeBSD Hackers , FreeBSD PowerPC ML X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 49MMj94FVbz4VB2 X-Spamd-Bar: / X-Spamd-Result: default: False [-0.97 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCPT_COUNT_SEVEN(0.00)[7]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-0.57)[-0.570,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.00)[ip: (4.89), ipnet: 98.137.64.0/21(0.83), asn: 36647(0.66), country: US(-0.05)]; NEURAL_SPAM_MEDIUM(0.10)[0.097,0]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[84.68.137.98.list.dnswl.org : 127.0.5.0]; RWL_MAILSPIKE_POSSIBLE(0.00)[84.68.137.98.rep.mailspike.net : 127.0.0.17]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2020 04:52:15 -0000 [Yet another new kind of experiment. But this looks like I can cause problems in fairly sort order on demand now. Finally! And with that I've much better evidence for kernel vs. user-space process for making the zeroed memory appear in, for example, nfsd.] I've managed to get: : = /usr/src/contrib/jemalloc/include/jemalloc/internal/arena_inlines_b.h:258:= Failed assertion: "slab =3D=3D extent_slab_get(extent)" : = /usr/src/contrib/jemalloc/include/jemalloc/internal/arena_inlines_b.h:258:= Failed assertion: "slab =3D=3D extent_slab_get(extent)" and eventually: [1] Segmentation fault (core dumped) stress -m 2 --vm-bytes 1700M from a user program (stress) while another machine was attempted an nfs mount during the stress activity: # mount -onoatime,soft ...:/ /mnt && umount /mnt && rpcinfo -s ... [tcp] ...:/: RPCPROG_MNT: RPC: Timed out (To get failure I may have to run the commands multiple times. Timing details against stress's activity seem to matter.) That failure lead to: # ls -ldT /*.core* -rw------- 1 root wheel 3899392 May 12 19:52:26 2020 /mountd.core # ls -ldT *.core* -rw------- 1 root wheel 2682880 May 12 20:00:26 2020 stress.core (Note which of nfsd, mountd, or rpcbind need not be fully repeatable. stress.core seems to be written twice, probably because of the -m 2 in use.) The context that let me do this was to first (on the 2 socket G4 with a full 2048 MiBYte RAM configuration): stress -m 2 --vm-bytes 1700M & Note that the stress command keeps the memory busy and causes paging to the swap/page space. I've not tried to make it just fit without paging or just barely paging or such. The original context did not involve paging or low RAM, so I do not expect paging to be required but can be involved. The stress program backtrace is different: 4827 return (tls_get_addr_slow(dtvp, index, offset)); 4828 } (gdb) bt -full #0 0x41831b04 in tls_get_addr_common (dtvp=3D0x4186c010, index=3D2, = offset=3D4294937444) at /usr/src/libexec/rtld-elf/rtld.c:4824 dtv =3D 0x0 #1 0x4182bfcc in __tls_get_addr (ti=3D) at = /usr/src/libexec/rtld-elf/powerpc/reloc.c:848 tp =3D p =3D #2 0x41a83464 in __get_locale () at = /usr/src/lib/libc/locale/xlocale_private.h:199 No locals. #3 fprintf (fp=3D0x41b355f8, fmt=3D0x1804cbc "%s: FAIL: [%lli] (%d) ") = at /usr/src/lib/libc/stdio/fprintf.c:57 ap =3D {{gpr =3D 2 '\002', fpr =3D 0 '\000', reserved =3D 20731, = overflow_arg_area =3D 0xffffdb78, reg_save_area =3D 0xffffdae8}} ret =3D #4 0x01802348 in main (argc=3D, argv=3D) = at stress.c:415 status =3D ret =3D 6 do_dryrun =3D 0 retval =3D 0 children =3D 1 do_backoff =3D do_hdd_bytes =3D do_hdd =3D do_vm_keep =3D 0 do_vm_hang =3D -1 do_vm_stride =3D 4096 do_vm_bytes =3D 1782579200 do_vm =3D 108174317627375616 do_io =3D do_cpu =3D do_timeout =3D 108176117243859333 starttime =3D 1589338322 i =3D forks =3D pid =3D 6140 stoptime =3D runtime =3D Apparently the asserts did not stop the code and it ran until a failure occurred (via dtv=3D0x0). Stress uses a mutex stored on a page that gets the "turns into zeros" problem, preventing the mprotect(ADDR,1,1) type of test because stress will write on the page. (I've not tried to find a minimal form of stress run.) The the same sort of globals are again zeroed, such as: (gdb) print/x __je_sz_size2index_tab $1 =3D {0x0 } Another attempt lost rpcbind instead instead of mountd: # ls -ldT /*.core -rw------- 1 root wheel 3899392 May 12 19:52:26 2020 /mountd.core -rw------- 1 root wheel 3170304 May 12 20:03:00 2020 /rpcbind.core I again find that when I use gdb 3 times to: attach ??? x/x __je_sz_size2index_tab print (int)mprotext(ADDRESS,1,1) quit for each of rpcbind, mountd, and nfsd master that those processes no longer fail during the mount/umount/rpcinfo (or are far less likely to). But it turns out that later when I "service nfsd stop" nfsd does get the zeroed Memory based assert and core dumps. (I'd done a bunch of the mount/umount/ rpcinfo sequences before the stop.) That the failure is during SIGUSR1 based shutdown, leads me to wonder if killing off some child process(es) is involved in the problem. There was *no* evidence of a signal for an attempt to write the page from the user process. It appears that the kernel is doing something that changes what the process sees --instead of the user-space programs stomping on its own memory content. I've no clue how to track down the kernel activity that changes what the process sees on some page(s) of memory. (Prior testing with a debug kernel did not report problems, despite getting an example failure. So that seems insufficient.) At least a procedure is now known that does not involved waiting hours or days. The procedure (adjusted for how much RAM is present and number of cpus/cores?) could be appropriate to run in other contexts than the 32-bit powerpc G4. Part of the context likely should be not using MALLOC_PRODUCTION --so problems would be detected sooner via the asserts in jemalloc. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-hackers@freebsd.org Wed May 13 06:32:28 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 9B7DE2EB0FE for ; Wed, 13 May 2020 06:32:28 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 49MPwr2lxLz4bHv for ; Wed, 13 May 2020 06:32:28 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mailman.nyi.freebsd.org (Postfix) id 5CA762EB0FC; Wed, 13 May 2020 06:32:28 +0000 (UTC) Delivered-To: hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 5C5772EB0F8; Wed, 13 May 2020 06:32:28 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mail-lf1-f48.google.com (mail-lf1-f48.google.com [209.85.167.48]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) 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 49MPwq3w76z4bHn; Wed, 13 May 2020 06:32:27 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mail-lf1-f48.google.com with SMTP id c21so7992910lfb.3; Tue, 12 May 2020 23:32:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:openpgp:autocrypt:message-id :date:user-agent:mime-version:content-language :content-transfer-encoding; bh=Mbo5G+POyWI/dgErMnyuXZ86nTTQ1Xn4vDqAOXQ23eg=; b=t9PxsPc3KmPiTW+PAWOtlMl8qOVBMUVbTkY2QTto/G8A/ZVmjMtZwytIg0a9NwWMoi /dx45tkPiURmVTv5Mfvfq4aVExTtA/LB1ovA3pcc+pmVm0CrOn9tYQMkc9UAHy94ul7P O1E7OplDya7c8voJXe5/6LKCDr204YUsmkzdvWT1+saZg9jN0fWKdbJd3fOGJq07S314 OlaEon7R2EawwkRBj2OvV7kAtAzpDTk/hiZkMYOjhs38hMChDJj6hvRH8Ae8I2yWzwx7 87hTUaBDtNzIhI8Gt/mV2kYC0pUKL0TYxuTytRxNA0s/R9m1dcjElc98EJcsPm7/bHM1 GLfQ== X-Gm-Message-State: AOAM530IO+/5qhYWnLGWKog8ea5X6QHdFm1hx6KYJ0eO3BOurg5rRrbQ psB8Dr2gNaDXB0+1duQWABVjpfl9siU= X-Google-Smtp-Source: ABdhPJzAg9kJ3Vy3gWiGpYsMycSXUQ/rcO+0k2y8ELDqv9G56BHXzCCl1AqPeClNsJVqbLwgvvQlfg== X-Received: by 2002:a05:6512:108f:: with SMTP id j15mr17082262lfg.19.1589351545479; Tue, 12 May 2020 23:32:25 -0700 (PDT) Received: from [192.168.0.88] (east.meadow.volia.net. [93.72.151.96]) by smtp.googlemail.com with ESMTPSA id r19sm13964358ljp.68.2020.05.12.23.32.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 12 May 2020 23:32:24 -0700 (PDT) To: FreeBSD Current , FreeBSD Hackers From: Andriy Gapon Subject: lkpi: print stack trace in WARN_ON ? Openpgp: preference=signencrypt Autocrypt: addr=avg@FreeBSD.org; prefer-encrypt=mutual; keydata= mQINBFm4LIgBEADNB/3lT7f15UKeQ52xCFQx/GqHkSxEdVyLFZTmY3KyNPQGBtyvVyBfprJ7 mAeXZWfhat6cKNRAGZcL5EmewdQuUfQfBdYmKjbw3a9GFDsDNuhDA2QwFt8BmkiVMRYyvI7l N0eVzszWCUgdc3qqM6qqcgBaqsVmJluwpvwp4ZBXmch5BgDDDb1MPO8AZ2QZfIQmplkj8Y6Z AiNMknkmgaekIINSJX8IzRzKD5WwMsin70psE8dpL/iBsA2cpJGzWMObVTtCxeDKlBCNqM1i gTXta1ukdUT7JgLEFZk9ceYQQMJJtUwzWu1UHfZn0Fs29HTqawfWPSZVbulbrnu5q55R4PlQ /xURkWQUTyDpqUvb4JK371zhepXiXDwrrpnyyZABm3SFLkk2bHlheeKU6Yql4pcmSVym1AS4 dV8y0oHAfdlSCF6tpOPf2+K9nW1CFA8b/tw4oJBTtfZ1kxXOMdyZU5fiG7xb1qDgpQKgHUX8 7Rd2T1UVLVeuhYlXNw2F+a2ucY+cMoqz3LtpksUiBppJhw099gEXehcN2JbUZ2TueJdt1FdS ztnZmsHUXLxrRBtGwqnFL7GSd6snpGIKuuL305iaOGODbb9c7ne1JqBbkw1wh8ci6vvwGlzx rexzimRaBzJxlkjNfMx8WpCvYebGMydNoeEtkWldtjTNVsUAtQARAQABtB5BbmRyaXkgR2Fw b24gPGF2Z0BGcmVlQlNELm9yZz6JAlQEEwEIAD4WIQS+LEO7ngQnXA4Bjr538m7TUc1yjwUC WbgsiAIbIwUJBaOagAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRB38m7TUc1yj+JAEACV l9AK/nOWAt/9cufV2fRj0hdOqB1aCshtSrwHk/exXsDa4/FkmegxXQGY+3GWX3deIyesbVRL rYdtdK0dqJyT1SBqXK1h3/at9rxr9GQA6KWOxTjUFURsU7ok/6SIlm8uLRPNKO+yq0GDjgaO LzN+xykuBA0FlhQAXJnpZLcVfPJdWv7sSHGedL5ln8P8rxR+XnmsA5TUaaPcbhTB+mG+iKFj GghASDSfGqLWFPBlX/fpXikBDZ1gvOr8nyMY9nXhgfXpq3B6QCRYKPy58ChrZ5weeJZ29b7/ QdEO8NFNWHjSD9meiLdWQaqo9Y7uUxN3wySc/YUZxtS0bhAd8zJdNPsJYG8sXgKjeBQMVGuT eCAJFEYJqbwWvIXMfVWop4+O4xB+z2YE3jAbG/9tB/GSnQdVSj3G8MS80iLS58frnt+RSEw/ psahrfh0dh6SFHttE049xYiC+cM8J27Aaf0i9RflyITq57NuJm+AHJoU9SQUkIF0nc6lfA+o JRiyRlHZHKoRQkIg4aiKaZSWjQYRl5Txl0IZUP1dSWMX4s3XTMurC/pnja45dge/4ESOtJ9R 8XuIWg45Oq6MeIWdjKddGhRj3OohsltKgkEU3eLKYtB6qRTQypHHUawCXz88uYt5e3w4V16H lCpSTZV/EVHnNe45FVBlvK7k7HFfDDkryLkCDQRZuCyIARAAlq0slcsVboY/+IUJdcbEiJRW be9HKVz4SUchq0z9MZPX/0dcnvz/gkyYA+OuM78dNS7Mbby5dTvOqfpLJfCuhaNYOhlE0wY+ 1T6Tf1f4c/uA3U/YiadukQ3+6TJuYGAdRZD5EqYFIkreARTVWg87N9g0fT9BEqLw9lJtEGDY EWUE7L++B8o4uu3LQFEYxcrb4K/WKmgtmFcm77s0IKDrfcX4doV92QTIpLiRxcOmCC/OCYuO jB1oaaqXQzZrCutXRK0L5XN1Y1PYjIrEzHMIXmCDlLYnpFkK+itlXwlE2ZQxkfMruCWdQXye syl2fynAe8hvp7Mms9qU2r2K9EcJiR5N1t1C2/kTKNUhcRv7Yd/vwusK7BqJbhlng5ZgRx0m WxdntU/JLEntz3QBsBsWM9Y9wf2V4tLv6/DuDBta781RsCB/UrU2zNuOEkSixlUiHxw1dccI 6CVlaWkkJBxmHX22GdDFrcjvwMNIbbyfQLuBq6IOh8nvu9vuItup7qemDG3Ms6TVwA7BD3j+ 3fGprtyW8Fd/RR2bW2+LWkMrqHffAr6Y6V3h5kd2G9Q8ZWpEJk+LG6Mk3fhZhmCnHhDu6CwN MeUvxXDVO+fqc3JjFm5OxhmfVeJKrbCEUJyM8ESWLoNHLqjywdZga4Q7P12g8DUQ1mRxYg/L HgZY3zfKOqcAEQEAAYkCPAQYAQgAJhYhBL4sQ7ueBCdcDgGOvnfybtNRzXKPBQJZuCyIAhsM BQkFo5qAAAoJEHfybtNRzXKPBVwQAKfFy9P7N3OsLDMB56A4Kf+ZT+d5cIx0Yiaf4n6w7m3i ImHHHk9FIetI4Xe54a2IXh4Bq5UkAGY0667eIs+Z1Ea6I2i27Sdo7DxGwq09Qnm/Y65ADvXs 3aBvokCcm7FsM1wky395m8xUos1681oV5oxgqeRI8/76qy0hD9WR65UW+HQgZRIcIjSel9vR XDaD2HLGPTTGr7u4v00UeTMs6qvPsa2PJagogrKY8RXdFtXvweQFz78NbXhluwix2Tb9ETPk LIpDrtzV73CaE2aqBG/KrboXT2C67BgFtnk7T7Y7iKq4/XvEdDWscz2wws91BOXuMMd4c/c4 OmGW9m3RBLufFrOag1q5yUS9QbFfyqL6dftJP3Zq/xe+mr7sbWbhPVCQFrH3r26mpmy841ym dwQnNcsbIGiBASBSKksOvIDYKa2Wy8htPmWFTEOPRpFXdGQ27awcjjnB42nngyCK5ukZDHi6 w0qK5DNQQCkiweevCIC6wc3p67jl1EMFY5+z+zdTPb3h7LeVnGqW0qBQl99vVFgzLxchKcl0 R/paSFgwqXCZhAKMuUHncJuynDOP7z5LirUeFI8qsBAJi1rXpQoLJTVcW72swZ42IdPiboqx NbTMiNOiE36GqMcTPfKylCbF45JNX4nF9ElM0E+Y8gi4cizJYBRr2FBJgay0b9Cp Message-ID: <99bdcbbc-402d-8ab0-262d-0e9732ecf995@FreeBSD.org> Date: Wed, 13 May 2020 09:32:23 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Firefox/60.0 Thunderbird/60.9.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 49MPwq3w76z4bHn X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of agapon@gmail.com designates 209.85.167.48 as permitted sender) smtp.mailfrom=agapon@gmail.com X-Spamd-Result: default: False [-1.22 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; SUBJECT_ENDS_QUESTION(1.00)[]; DMARC_NA(0.00)[FreeBSD.org]; RCVD_TLS_ALL(0.00)[]; NEURAL_HAM_LONG(-0.99)[-0.994,0]; RCVD_COUNT_THREE(0.00)[3]; IP_SCORE(-0.24)[ip: (-0.32), ipnet: 209.85.128.0/17(-0.39), asn: 15169(-0.42), country: US(-0.05)]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[48.167.85.209.list.dnswl.org : 127.0.5.0]; NEURAL_HAM_MEDIUM(-0.98)[-0.984,0]; FORGED_SENDER(0.30)[avg@FreeBSD.org,agapon@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[48.167.85.209.rep.mailspike.net : 127.0.0.17]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[avg@FreeBSD.org,agapon@gmail.com]; RECEIVED_SPAMHAUS_PBL(0.00)[96.151.72.93.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2020 06:32:28 -0000 Just to get a bigger exposure: https://reviews.freebsd.org/D24779 I think that this is a good idea and, if I am not mistaken, it should match the Linux behavior. -- Andriy Gapon From owner-freebsd-hackers@freebsd.org Wed May 13 07:29:15 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 7D0FA2EC837 for ; Wed, 13 May 2020 07:29:15 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-19.consmr.mail.gq1.yahoo.com (sonic306-19.consmr.mail.gq1.yahoo.com [98.137.68.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49MRBL1pvKz4fRD for ; Wed, 13 May 2020 07:29:14 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: 8E92OWQVM1kjx.V0psqp37JR0A6OiadqLBqZxQTMpzvpvQd1SkZB.qC7qV8g7ol 8gaY51lNKSWHU4BNFKBk3YJb3lfPFUbLWRZizXuHFUqmTspoEWdZvTJU2eRbEWyfSgNYzCh2iBTF DTfgsd6xX8KaxR8yel7fDrqmtXOZGSSIHWKpxzkh2YkzQutzyxBoqAcnGL7IzB_hsVmhZxgb1169 bATqjm8K0dz636t3ZfeodD4qSzT34FaSQuPO1N_e3CMNLby9XF5.8spuXMqMkhFHtuwhzTqkgSjJ QKzBUqswkTIRElp1gRjwRZf4p.aa_ycWsbVKHCEI5rw7qOOce4pUuPBUd6UMF.N6WV6jForvheAY LRYzxp_88bf_2LKZr9I_NXZpewnBWkj4pcpdZOV0tuliy8RlS1vm4V5hZrU724sq9u4c1Gs59pKS G313r_3uCAnRVhKCH6TsGOx6MVovfSySqDj3AcBRn1f.oKotJggpaLJQ6I1RO2yRBkXoW0B4VVoN Y38XsFDWo3uB8qSXg5Ml10dTQuP9s_EGw5vXC_LoxloopBgnPo2F1IAT0VkyeZoJV6IISecLX1QF tWkiImhP4H0SQeQ0HzeaWbOhuplX8QwBy915kkdNKo_wDaT9KNmO9ac1vrm2qhZLGYqj5w3M2tsY KdolnuE_iVdIvqFkpl2mC6lezmTAkKR0TvVneUChgYdes9UHz0v3D9MDfJ2dYt5OVFdoXcDk0_M1 6QwavDlXXvIY5SmYBlCgn1NImFsG6poFajjyrIrK6N4ocBolHCcfirzT5hk.Sc2j6sd8DlyAfLOR qjTMvD0Bdvb02QeA7S6zW8UgGsF.jz8i5Z9xqzqDOC9FS0CCt73Ui1eiN.zmruUTo7rer_WDWtNI 73wtd339a66u4H9tjkagzG3laydaw72wyz9950mW9pOABNj3jq2ohaR2mliHtgemrUnCPsRPEE6. 9wTebdW224Taq7ObWJ55Se1AsgSqH2IAwqDSp3bCwJ2D3vS7nV.C9699ilm9jXQ3YeZTnr5e898. VZ4s_2KQ1XRFcsoZg9r6pRDjprtuxCLt1UbB_T.aKzIla7EPZwVGoZ7S8ZRfv9PxEulXh096qcD4 wgPeDCi_3rTxfPR8AxoTVe68nQmIlk3CcqagKTIt8L8eUwHn5fZ.8a0Y1Yxa4gyLSI51bCNxpicQ Uj3gF1LYfB.O3eqaG2bQOBNFDWAIPyNtI3WIjtiR4VmCoTm9H63kyCNc0LDhPU0uGjwF1Mq8aOQ. Uu0EgnIRqcyb9mb4n3R2Ggr7pPBa6KT9.cUwHwmkrffdDp5a.LTsPc6GieVm5B5QhN3ibcFgZM9h BE3mvXu0UUiRyzsXS6ytAADOIvvS8gtf9ExIw_jXWeSCbeCHrS.upSmanMQkoyioF5fy5IEKMnHw mLDtAYnez5Ll3Bn0QhdwMJMXiYkC2Xr2Ln7It8l7fXHW_Ll61rrrPHaP6jP514H_FPw-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Wed, 13 May 2020 07:29:12 +0000 Received: by smtp412.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 8bcb3d014077aa2d68dc334f30fdedbe; Wed, 13 May 2020 07:29:08 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: svn commit: r360233 - in head: contrib/jemalloc . . . : This partially breaks a 2-socket 32-bit powerpc (old PowerMac G4) based on head -r360311 From: Mark Millard In-Reply-To: <9562EEE4-62EF-4164-91C0-948CC0432984@yahoo.com> Date: Wed, 13 May 2020 00:29:07 -0700 Cc: Brandon Bergren , Justin Hibbits Content-Transfer-Encoding: quoted-printable Message-Id: <9B68839B-AEC8-43EE-B3B6-B696A4A57DAE@yahoo.com> References: <8479DD58-44F6-446A-9CA5-D01F0F7C1B38@yahoo.com> <17ACDA02-D7EF-4F26-874A-BB3E935CD072@yahoo.com> <695E6836-F860-4557-B7DE-CC1EDB347F18@yahoo.com> <121B9B09-141B-4DC3-918B-1E7CFB99E779@yahoo.com> <8AAB0462-3FA8-490C-8D8D-7C15B1C9E2DE@yahoo.com> <18E62746-80DB-4195-977D-4FF32D0129EE@yahoo.com> <9562EEE4-62EF-4164-91C0-948CC0432984@yahoo.com> To: "vangyzen@freebsd.org" , svn-src-head@freebsd.org, FreeBSD Current , FreeBSD Hackers , FreeBSD PowerPC ML X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 49MRBL1pvKz4fRD X-Spamd-Bar: - X-Spamd-Result: default: False [-1.10 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCPT_COUNT_SEVEN(0.00)[7]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.21)[-0.208,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-0.40)[-0.395,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.00)[ip: (5.37), ipnet: 98.137.64.0/21(0.83), asn: 36647(0.66), country: US(-0.05)]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[82.68.137.98.list.dnswl.org : 127.0.5.0]; RWL_MAILSPIKE_POSSIBLE(0.00)[82.68.137.98.rep.mailspike.net : 127.0.0.17]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2020 07:29:15 -0000 [stress alone is sufficient to have jemalloc asserts fail in stress, no need for a multi-socket G4 either. No need to involve nfsd, mountd, rpcbind or the like. This is not a claim that I know all the problems to be the same, just that a jemalloc reported failure in this simpler context happens and zeroed pages are involved.] Reminder: head -r360311 based context. First I show a single CPU/core PowerMac G4 context failing in stress. (I actually did this later, but it is the simpler context.) I simply moved the media from the 2-socket G4 to this slower, single-cpu/core one. cpu0: Motorola PowerPC 7400 revision 2.9, 466.42 MHz cpu0: Features 9c000000 cpu0: HID0 8094c0a4 real memory =3D 1577857024 (1504 MB) avail memory =3D 1527508992 (1456 MB) # stress -m 1 --vm-bytes 1792M stress: info: [1024] dispatching hogs: 0 cpu, 0 io, 1 vm, 0 hdd : = /usr/src/contrib/jemalloc/include/jemalloc/internal/arena_inlines_b.h:258:= Failed assertion: "slab =3D=3D extent_slab_get(extent)" stress: FAIL: [1024] (415) <-- worker 1025 got signal 6 stress: WARN: [1024] (417) now reaping child worker processes stress: FAIL: [1024] (451) failed run completed in 243s (Note: 1792 is the biggest it allowed with M.) The following still pages in and out and fails: # stress -m 1 --vm-bytes 1290M stress: info: [1163] dispatching hogs: 0 cpu, 0 io, 1 vm, 0 hdd : = /usr/src/contrib/jemalloc/include/jemalloc/internal/arena_inlines_b.h:258:= Failed assertion: "slab =3D=3D extent_slab_get(extent)" . . . By contrast, the following had no problem for as long as I let it run --and did not page in or out: # stress -m 1 --vm-bytes 1280M stress: info: [1181] dispatching hogs: 0 cpu, 0 io, 1 vm, 0 hdd The 2 socket PowerMac G4 context with 2048 MiByte of RAM . . . stress -m 1 --vm-bytes 1792M did not (quickly?) fail or page. 1792 is as large as it would allow with M. The following also did not (quickly?) fail (and were not paging): stress -m 2 --vm-bytes 896M stress -m 4 --vm-bytes 448M stress -m 8 --vm-bytes 224M (Only 1 example was run at a time.) But the following all did quickly fail (and were paging): stress -m 8 --vm-bytes 225M stress -m 4 --vm-bytes 449M stress -m 2 --vm-bytes 897M (Only 1 example was run at a time.) I'll note that when I exited an su process I ended up with a: : = /usr/src/contrib/jemalloc/include/jemalloc/internal/sz.h:200: Failed = assertion: "ret =3D=3D sz_index2size_compute(index)" Abort trap (core dumped) and a matching su.core file. It appears that stress's activity leads to other processes also seeing examples of the zeroed-page(s) problem (probably su had paged some or had been fully swapped out): (gdb) bt #0 thr_kill () at thr_kill.S:4 #1 0x503821d0 in __raise (s=3D6) at /usr/src/lib/libc/gen/raise.c:52 #2 0x502e1d20 in abort () at /usr/src/lib/libc/stdlib/abort.c:67 #3 0x502d6144 in sz_index2size_lookup (index=3D) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/sz.h:200 #4 sz_index2size (index=3D) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/sz.h:207 #5 ifree (tsd=3D0x5008b018, ptr=3D0x50041460, tcache=3D0x5008b138, = slow_path=3D) at jemalloc_jemalloc.c:2583 #6 0x502d5cec in __je_free_default (ptr=3D0x50041460) at = jemalloc_jemalloc.c:2784 #7 0x502d62d4 in __free (ptr=3D0x50041460) at jemalloc_jemalloc.c:2852 #8 0x501050cc in openpam_destroy_chain (chain=3D0x50041480) at = /usr/src/contrib/openpam/lib/libpam/openpam_load.c:113 #9 0x50105094 in openpam_destroy_chain (chain=3D0x500413c0) at = /usr/src/contrib/openpam/lib/libpam/openpam_load.c:111 #10 0x50105094 in openpam_destroy_chain (chain=3D0x50041320) at = /usr/src/contrib/openpam/lib/libpam/openpam_load.c:111 #11 0x50105094 in openpam_destroy_chain (chain=3D0x50041220) at = /usr/src/contrib/openpam/lib/libpam/openpam_load.c:111 #12 0x50105094 in openpam_destroy_chain (chain=3D0x50041120) at = /usr/src/contrib/openpam/lib/libpam/openpam_load.c:111 #13 0x50105094 in openpam_destroy_chain (chain=3D0x50041100) at = /usr/src/contrib/openpam/lib/libpam/openpam_load.c:111 #14 0x50105014 in openpam_clear_chains (policy=3D0x50600004) at = /usr/src/contrib/openpam/lib/libpam/openpam_load.c:130 #15 0x50101230 in pam_end (pamh=3D0x50600000, status=3D) = at /usr/src/contrib/openpam/lib/libpam/pam_end.c:83 #16 0x1001225c in main (argc=3D, argv=3D0x0) at = /usr/src/usr.bin/su/su.c:477 (gdb) print/x __je_sz_size2index_tab $1 =3D {0x0 } Notes: Given that the original problem did not involve paging to the swap partition, may be just making it to the Laundry list or some such is sufficient, something that is also involved when the swap space is partially in use (according to top). Or sitting in the inactive list for a long time, if that has some special status. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-hackers@freebsd.org Wed May 13 08:43:29 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id EEDE12EEE7B for ; Wed, 13 May 2020 08:43:29 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-23.consmr.mail.gq1.yahoo.com (sonic312-23.consmr.mail.gq1.yahoo.com [98.137.69.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49MSr01lGmz3HXs for ; Wed, 13 May 2020 08:43:27 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: JcuqEyYVM1n16L7Heovzfmq3h815crg5hv6fPDYHSgs3lYKXCy8a1eN2_Mi220S gJc9X_k0O.CEoYEzkCzEDyKdhOrnJ90g85NRM_h9r.V7TrP7YUa7_LisQE.o4zZFwsNHaYO1gbUe CPkdim9V713ydBMaSqY7lDePBz_6PK4aN6Dakwf1RvuxlrJkIbzhYRkfEhJ40Thq.k7mxGDYMAuC TUD0C_CccVPYBmqWUBAAFINIUylfbjOtovyxsdNy4jsNfTJR7QbdI0be0K5NVKyQs2CJ3CSHLPtd Q2VkYoRYn9YnxBl_W26auilF9PAT7u3V1.BD.RvpedUqHbUngsTDqpp6Kocv6FV1P01ehsYwMu9h McNzQLqg68Ku9ensOfg2wL3m4Tm0LOsQzsnCWd4mfRqMxmUztNzaJ7OJMqBaMju0KJbwScRkYTdo ZYtFigJWxSQgs.HXwV6PxC3Owya9UuzySnTRdqQURm60ZA0y2fRCl8vH7D0ebMcTtot5kvOineU0 gjHZocjZDLRbgj6hfQYB3ESVfFUNPLW1v0LD4ltC_u6QydxZJ.6hvq6xZMYpQeMpqoVvB22LnhLY Q1GOYNCvpY.7ZpWHA529itWO7J3bV3lMTwe7jTV7OErQTasHp5bZFD2AYhRtoqlJ4gxEL0tyzE.3 MepGbWH0.IYZMaUlXMksZnuOBJdvWywdWprjstKQrnpTaR2fBb2.FQZ5Qt1CsKi6b5E8B5aITvv4 WnZnghA9tDeYeVaC5pkC.8OJ5MDCWMnhSGcKTOi8oI7W7_iAK2daAYfyE5TNk9zaI7dVRIsku5D3 9seL1Z_92ReB1PfYtMUfzfnScbt5h2BsbTSk7FkVDbCzcThtsZBh9j37lrlpP.3XjYjY_GPD9sCC vh2dmeWa4b.OLsXVBj1uU9CqkBgcQHiHM0ZluYF.2fNABtcCuxE4Wv7nAQD5Ghwxloucdbl4636b nTK2vlvE1j3Fdg5RPLVjqMW5Vr9wPawK46HV9G.QPf1C2joZ32_z9mOjdqJ5KiQdXkc3M7TvnDh6 SX_yPgjAjLydeDx8bVty6mX3c93i5wHLcVI8uVEezaIt8IYafcepOq8v9tc5umKY2Or0Pr0tKVhc ifaE6Degc4s9L8Sb.rLOlgG7ofUk2_a6rz1sRQAyRL7AKeqRtJqLbBknf_Z1Ts1JfzRwSanh56Pz ygElbWOpjUF6PvFATIdsO21haNucI25G1nNCLXrxcnv0z3JIC1UTLRviMdWNjETbjakv_OMMnObC Ibp6JFKTbqLAMi3T0gTKfytgjV1OAzAeJmRGYfrmv8pFyNvF.wNwExAsL4kl80ogHXitYrb42M0a Yq2SiEkHQx3UTSEPVCEAtKmoS5nBcpr8G.PNFOgK.5gCtMGsrGpiG20bgDDurGxnCbOO0.4uIQEK u_IqjEFJp5StoiUGIaKG1gOXI9mldbmQ- Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Wed, 13 May 2020 08:43:26 +0000 Received: by smtp429.mail.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 31a8d8875d7f20b3e1c3e41b2146484f; Wed, 13 May 2020 08:43:24 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: svn commit: r360233 - in head: contrib/jemalloc . . . : This partially breaks a 2-socket 32-bit powerpc (old PowerMac G4) based on head -r360311 From: Mark Millard In-Reply-To: <9B68839B-AEC8-43EE-B3B6-B696A4A57DAE@yahoo.com> Date: Wed, 13 May 2020 01:43:23 -0700 Cc: Brandon Bergren , Justin Hibbits Content-Transfer-Encoding: quoted-printable Message-Id: <359C9C7D-4106-42B5-AAB5-08EF995B8100@yahoo.com> References: <8479DD58-44F6-446A-9CA5-D01F0F7C1B38@yahoo.com> <17ACDA02-D7EF-4F26-874A-BB3E935CD072@yahoo.com> <695E6836-F860-4557-B7DE-CC1EDB347F18@yahoo.com> <121B9B09-141B-4DC3-918B-1E7CFB99E779@yahoo.com> <8AAB0462-3FA8-490C-8D8D-7C15B1C9E2DE@yahoo.com> <18E62746-80DB-4195-977D-4FF32D0129EE@yahoo.com> <9562EEE4-62EF-4164-91C0-948CC0432984@yahoo.com> <9B68839B-AEC8-43EE-B3B6-B696A4A57DAE@yahoo.com> To: "vangyzen@freebsd.org" , svn-src-head@freebsd.org, FreeBSD Current , FreeBSD Hackers , FreeBSD PowerPC ML X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 49MSr01lGmz3HXs X-Spamd-Bar: - X-Spamd-Result: default: False [-1.04 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCPT_COUNT_SEVEN(0.00)[7]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.18)[-0.176,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-0.36)[-0.364,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.00)[ip: (5.09), ipnet: 98.137.64.0/21(0.83), asn: 36647(0.66), country: US(-0.05)]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[204.69.137.98.list.dnswl.org : 127.0.5.0]; RWL_MAILSPIKE_POSSIBLE(0.00)[204.69.137.98.rep.mailspike.net : 127.0.0.17]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2020 08:43:30 -0000 [I'm adding a reference to an old arm64/aarch64 bug that had pages turning to zero, in case this 32-bit powerpc issue is somewhat analogous.] On 2020-May-13, at 00:29, Mark Millard wrote: > [stress alone is sufficient to have jemalloc asserts fail > in stress, no need for a multi-socket G4 either. No need > to involve nfsd, mountd, rpcbind or the like. This is not > a claim that I know all the problems to be the same, just > that a jemalloc reported failure in this simpler context > happens and zeroed pages are involved.] >=20 > Reminder: head -r360311 based context. >=20 >=20 > First I show a single CPU/core PowerMac G4 context failing > in stress. (I actually did this later, but it is the > simpler context.) I simply moved the media from the > 2-socket G4 to this slower, single-cpu/core one. >=20 > cpu0: Motorola PowerPC 7400 revision 2.9, 466.42 MHz > cpu0: Features 9c000000 > cpu0: HID0 8094c0a4 > real memory =3D 1577857024 (1504 MB) > avail memory =3D 1527508992 (1456 MB) >=20 > # stress -m 1 --vm-bytes 1792M > stress: info: [1024] dispatching hogs: 0 cpu, 0 io, 1 vm, 0 hdd > : = /usr/src/contrib/jemalloc/include/jemalloc/internal/arena_inlines_b.h:258:= Failed assertion: "slab =3D=3D extent_slab_get(extent)" > stress: FAIL: [1024] (415) <-- worker 1025 got signal 6 > stress: WARN: [1024] (417) now reaping child worker processes > stress: FAIL: [1024] (451) failed run completed in 243s >=20 > (Note: 1792 is the biggest it allowed with M.) >=20 > The following still pages in and out and fails: >=20 > # stress -m 1 --vm-bytes 1290M > stress: info: [1163] dispatching hogs: 0 cpu, 0 io, 1 vm, 0 hdd > : = /usr/src/contrib/jemalloc/include/jemalloc/internal/arena_inlines_b.h:258:= Failed assertion: "slab =3D=3D extent_slab_get(extent)" > . . . >=20 > By contrast, the following had no problem for as > long as I let it run --and did not page in or out: >=20 > # stress -m 1 --vm-bytes 1280M > stress: info: [1181] dispatching hogs: 0 cpu, 0 io, 1 vm, 0 hdd >=20 >=20 >=20 >=20 > The 2 socket PowerMac G4 context with 2048 MiByte of RAM . . . >=20 > stress -m 1 --vm-bytes 1792M >=20 > did not (quickly?) fail or page. 1792 > is as large as it would allow with M. >=20 > The following also did not (quickly?) fail > (and were not paging): >=20 > stress -m 2 --vm-bytes 896M > stress -m 4 --vm-bytes 448M > stress -m 8 --vm-bytes 224M >=20 > (Only 1 example was run at a time.) >=20 > But the following all did quickly fail (and were > paging): >=20 > stress -m 8 --vm-bytes 225M > stress -m 4 --vm-bytes 449M > stress -m 2 --vm-bytes 897M >=20 > (Only 1 example was run at a time.) >=20 > I'll note that when I exited an su process > I ended up with a: >=20 > : = /usr/src/contrib/jemalloc/include/jemalloc/internal/sz.h:200: Failed = assertion: "ret =3D=3D sz_index2size_compute(index)" > Abort trap (core dumped) >=20 > and a matching su.core file. It appears > that stress's activity leads to other > processes also seeing examples of the > zeroed-page(s) problem (probably su had > paged some or had been fully swapped > out): >=20 > (gdb) bt > #0 thr_kill () at thr_kill.S:4 > #1 0x503821d0 in __raise (s=3D6) at /usr/src/lib/libc/gen/raise.c:52 > #2 0x502e1d20 in abort () at /usr/src/lib/libc/stdlib/abort.c:67 > #3 0x502d6144 in sz_index2size_lookup (index=3D) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/sz.h:200 > #4 sz_index2size (index=3D) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/sz.h:207 > #5 ifree (tsd=3D0x5008b018, ptr=3D0x50041460, tcache=3D0x5008b138, = slow_path=3D) at jemalloc_jemalloc.c:2583 > #6 0x502d5cec in __je_free_default (ptr=3D0x50041460) at = jemalloc_jemalloc.c:2784 > #7 0x502d62d4 in __free (ptr=3D0x50041460) at = jemalloc_jemalloc.c:2852 > #8 0x501050cc in openpam_destroy_chain (chain=3D0x50041480) at = /usr/src/contrib/openpam/lib/libpam/openpam_load.c:113 > #9 0x50105094 in openpam_destroy_chain (chain=3D0x500413c0) at = /usr/src/contrib/openpam/lib/libpam/openpam_load.c:111 > #10 0x50105094 in openpam_destroy_chain (chain=3D0x50041320) at = /usr/src/contrib/openpam/lib/libpam/openpam_load.c:111 > #11 0x50105094 in openpam_destroy_chain (chain=3D0x50041220) at = /usr/src/contrib/openpam/lib/libpam/openpam_load.c:111 > #12 0x50105094 in openpam_destroy_chain (chain=3D0x50041120) at = /usr/src/contrib/openpam/lib/libpam/openpam_load.c:111 > #13 0x50105094 in openpam_destroy_chain (chain=3D0x50041100) at = /usr/src/contrib/openpam/lib/libpam/openpam_load.c:111 > #14 0x50105014 in openpam_clear_chains (policy=3D0x50600004) at = /usr/src/contrib/openpam/lib/libpam/openpam_load.c:130 > #15 0x50101230 in pam_end (pamh=3D0x50600000, status=3D) at /usr/src/contrib/openpam/lib/libpam/pam_end.c:83 > #16 0x1001225c in main (argc=3D, argv=3D0x0) at = /usr/src/usr.bin/su/su.c:477 >=20 > (gdb) print/x __je_sz_size2index_tab > $1 =3D {0x0 } >=20 >=20 > Notes: >=20 > Given that the original problem did not involve > paging to the swap partition, may be just making > it to the Laundry list or some such is sufficient, > something that is also involved when the swap > space is partially in use (according to top). Or > sitting in the inactive list for a long time, if > that has some special status. >=20 The following is was a fix for a "pages magically turn into zeros" problem on amd64/aarch64. The original 32-bit powerpc context did not seem a match to me --but the stress test behavior that I've just observed seems closer from an external-test point of view: swapping is involved. My be this will suggest something to someone that knows what they are doing. (Note: dsl-only.net closed down, so the E-mail address reference is no longer valid.) Author: kib Date: Mon Apr 10 15:32:26 2017 New Revision: 316679 URL:=20 https://svnweb.freebsd.org/changeset/base/316679 Log: Do not lose dirty bits for removing PROT_WRITE on arm64. Arm64 pmap interprets accessed writable ptes as modified, since ARMv8.0 does not track Dirty Bit Modifier in hardware. If writable bit is removed, page must be marked as dirty for MI VM. This change is most important for COW, where fork caused losing content of the dirty pages which were not yet scanned by pagedaemon. Reviewed by: alc, andrew Reported and tested by: Mark Millard PR: 217138, 217239 Sponsored by: The FreeBSD Foundation MFC after: 2 weeks Modified: head/sys/arm64/arm64/pmap.c Modified: head/sys/arm64/arm64/pmap.c = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D --- head/sys/arm64/arm64/pmap.c Mon Apr 10 12:35:58 2017 = (r316678) +++ head/sys/arm64/arm64/pmap.c Mon Apr 10 15:32:26 2017 = (r316679) @@ -2481,6 +2481,11 @@ pmap_protect(pmap_t pmap, vm_offset_t sv sva +=3D L3_SIZE) { l3 =3D pmap_load(l3p); if (pmap_l3_valid(l3)) { + if ((l3 & ATTR_SW_MANAGED) && + pmap_page_dirty(l3)) { + vm_page_dirty(PHYS_TO_VM_PAGE(l3 = & + ~ATTR_MASK)); + } pmap_set(l3p, ATTR_AP(ATTR_AP_RO)); PTE_SYNC(l3p); /* XXX: Use pmap_invalidate_range */ =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-hackers@freebsd.org Thu May 14 20:17:22 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 152EC2DDBD2 for ; Thu, 14 May 2020 20:17:22 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 49NNB94tBsz3Mfj for ; Thu, 14 May 2020 20:17:21 +0000 (UTC) (envelope-from jhs@berklix.com) Received: by mailman.nyi.freebsd.org (Postfix) id A71122DDBC4; Thu, 14 May 2020 20:17:21 +0000 (UTC) Delivered-To: hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id A6A472DDBC3; Thu, 14 May 2020 20:17:21 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from slim.berklix.org (slim.berklix.org [94.185.90.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "slim.berklix.org", Issuer "slim.berklix.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 49NNB73y3pz3MfK; Thu, 14 May 2020 20:17:18 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from mart.js.berklix.net (p5ddb7209.dip0.t-ipconnect.de [93.219.114.9]) (authenticated bits=128) by slim.berklix.org (8.15.2/8.15.2) with ESMTPSA id 04EKHBXi052956 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 May 2020 22:17:15 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id 04EKHAnD091168; Thu, 14 May 2020 22:17:11 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.7/8.14.7) with ESMTP id 04EKH0aA093503; Thu, 14 May 2020 22:17:10 +0200 (CEST) (envelope-from jhs@berklix.com) Message-Id: <202005142017.04EKH0aA093503@fire.js.berklix.net> To: Kyle Evans cc: "freebsd-arch@freebsd.org" , hackers@freebsd.org Subject: Re: [HEADSUP] Disallowing read() of a directory fd From: "Julian H. Stacey" Organization: http://berklix.com/jhs http://stolenvotes.uk User-agent: EXMH on FreeBSD http://berklix.com/free/ X-From: http://www.berklix.org/~jhs/ In-reply-to: Your message "Thu, 14 May 2020 13:26:46 -0500." Date: Thu, 14 May 2020 22:17:00 +0200 X-Rspamd-Queue-Id: 49NNB73y3pz3MfK X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of jhs@berklix.com has no SPF policy when checking 94.185.90.68) smtp.mailfrom=jhs@berklix.com X-Spamd-Result: default: False [0.16 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[berklix.com]; AUTH_NA(1.00)[]; HAS_ORG_HEADER(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; IP_SCORE(-0.00)[ip: (0.01), ipnet: 94.185.88.0/22(0.01), asn: 33824(-0.00), country: DE(-0.02)]; NEURAL_SPAM_LONG(0.01)[0.011,0]; RCVD_IN_DNSWL_NONE(0.00)[68.90.185.94.list.dnswl.org : 127.0.10.0]; NEURAL_HAM_MEDIUM(-0.75)[-0.750,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:33824, ipnet:94.185.88.0/22, country:DE]; RCVD_TLS_LAST(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[9.114.219.93.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2020 20:17:22 -0000 Kyle Evans wrote: > Hi, > > This is a heads up, given that I'm completely flipping our historical > behavior- I intend to commit this review in a couple days' time > without substantial objection: https://reviews.freebsd.org/D24596 > > With this, FreeBSD 13 will not allow read() of a directory fd, which > could have previously returned some data from the underlying > filesystem in no particular standardized format. > > This is a still-standards-compliant switch from one > implementation-defined behavior to another that's already been adopted > in various other popular kernels, to include OpenBSD, MacOS, and > Linux. > > Worth noting is that there's not really one largely-compelling reasons > to switch this after so many years (unless you find yourself that > irate when you accidentally `cat` a directory), but there are some > benefits which are briefly discussed in the commentary around the > review along with the history of the current behavior. > > This change also simplifies filesystem implementations to some extent. > > Thanks, > > Kyle Evans There is ZERO need for a spurious change at 2 days notice after 42+ years ! "cat ." as been supported since Unix V6 1978 or earlier, no problem, even occasionaly useful. Most FreeBSD users wont have heard of https://reviews.freebsd.org/D24596 (& there's only 5 other people's opinions there, apart from proposer, & skimming through the impression is far from un-qualified approval. kevans@ issued arch@ just a couple days notice of intention to commit. arch@ is also not widely read, ( I jhs@ added CC hackers@) Many FreeBSD end users won't even be reading hackers@ (some not even announce@,) & would notice just yet another pointless change sometime after upgrade. Do not force all FreeBSD users towards gratuitous change for personal preference for Linux behaviour. Switch to Linux, Or hack a personalised shell on BSD that does what you want when you type "cat ." If it's later widely popular, use it as proof to re-propose. No Rush. A bigger issue is due notice procedure, & respect to FreeBSD stability of code & users expectations of predictability. Unwarned playing about would detract from FreeBSD's business image. Cheers -- Julian Stacey, Consultant Systems Engineer, BSD Linux http://berklix.com/jhs/ http://www.berklix.org/corona/#masks Tie 2 handkerchiefs or 1 pillow case. Jobs & economy hit by Corona to be hit again by Crash Brexit 31st Dec. 2020 From owner-freebsd-hackers@freebsd.org Thu May 14 20:18:51 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 370262DDEE2 for ; Thu, 14 May 2020 20:18:51 +0000 (UTC) (envelope-from pjfloyd@wanadoo.fr) Received: from smtp.smtpout.orange.fr (smtp09.smtpout.orange.fr [80.12.242.131]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "Bizanga Labs SMTP Client Certificate", Issuer "Bizanga Labs CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 49NNCr3919z3N05 for ; Thu, 14 May 2020 20:18:47 +0000 (UTC) (envelope-from pjfloyd@wanadoo.fr) Received: from wwinf1n11 ([10.223.72.54]) by mwinf5d17 with ME id ekJk220021AGQpE03kJkn1; Thu, 14 May 2020 22:18:44 +0200 X-ME-Helo: wwinf1n11 X-ME-Auth: cGpmbG95ZEB3YW5hZG9vLmZy X-ME-Date: Thu, 14 May 2020 22:18:44 +0200 X-ME-IP: 2.7.113.176 Date: Thu, 14 May 2020 22:18:44 +0200 (CEST) From: Paul FLOYD Reply-To: Paul FLOYD To: freebsd-hackers@freebsd.org Message-ID: <2102917207.11671.1589487524169.JavaMail.www@wwinf1n11> Subject: SIGBUS si_code 12 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [2.7.113.176] X-WUM-FROM: |~| X-WUM-TO: |~| X-WUM-REPLYTO: |~| X-Rspamd-Queue-Id: 49NNCr3919z3N05 X-Spamd-Bar: +++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of pjfloyd@wanadoo.fr has no SPF policy when checking 80.12.242.131) smtp.mailfrom=pjfloyd@wanadoo.fr X-Spamd-Result: default: False [3.39 / 15.00]; HAS_REPLYTO(0.00)[pjfloyd@wanadoo.fr]; HAS_XOIP(0.00)[]; FREEMAIL_FROM(0.00)[wanadoo.fr]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:3215, ipnet:80.12.240.0/20, country:FR]; IP_SCORE(0.00)[ip: (2.68), ipnet: 80.12.240.0/20(1.72), asn: 3215(2.40), country: FR(-0.00)]; FREEMAIL_ENVFROM(0.00)[wanadoo.fr]; ARC_NA(0.00)[]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_REPLYTO(0.00)[wanadoo.fr]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.99)[0.987,0]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE_FREEMAIL(0.00)[]; MIME_TRACE(0.00)[0:+]; NEURAL_SPAM_LONG(1.00)[1.000,0]; RCVD_IN_DNSWL_NONE(0.00)[131.242.12.80.list.dnswl.org : 127.0.5.0]; R_SPF_NA(0.00)[]; DMARC_NA(0.00)[wanadoo.fr]; RWL_MAILSPIKE_POSSIBLE(0.00)[131.242.12.80.rep.mailspike.net : 127.0.0.17]; MID_RHS_NOT_FQDN(0.50)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2020 20:18:51 -0000 Hi =C2=A0 It seems as though SIGBUS=C2=A0can have an si_code of 12.=20 This isn't documented in the siginfo manpage (https://www.freebsd.org/cgi/m= an.cgi?query=3Dsiginfo&apropos=3D0&sektion=3D3&manpath=3DFreeBSD+12.1- RELEASE+and+Ports&arch=3Ddefault&format=3Dhtml). which only covers these 3 = values for si_code. SIGBUS BUS_ADRALN invalid address alignment BUS_ADRERR nonexistent physical address BUS_OBJERR object-specific hardware error Is this a defect in the siginfo documentation? Here's an extract from trap.c that shows this. if (signo =3D=3D SIGSEGV) { ucode =3D SEGV_MAPERR; } else if (prot_fault_translation =3D=3D 0) { /* * Autodetect. This check also covers * the images without the ABI-tag ELF * note. */ if (SV_CURPROC_ABI() =3D=3D SV_ABI_FREEBSD && p->p_osrel >=3D P_OSREL_SIGSEGV) { signo =3D SIGSEGV; ucode =3D SEGV_ACCERR; } else { signo =3D SIGBUS; ucode =3D T_PAGEFLT; } } else if (prot_fault_translation =3D=3D 1) { /* * Always compat mode. */ signo =3D SIGBUS; ucode =3D T_PAGEFLT; } A+ Paul From owner-freebsd-hackers@freebsd.org Thu May 14 20:20:59 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id AC0982DE0E8 for ; Thu, 14 May 2020 20:20:59 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 49NNGM304Jz3NBH for ; Thu, 14 May 2020 20:20:59 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mailman.nyi.freebsd.org (Postfix) id 6478E2DE0E6; Thu, 14 May 2020 20:20:59 +0000 (UTC) Delivered-To: hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 642382DE0E5; Thu, 14 May 2020 20:20:59 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-oo1-f68.google.com (mail-oo1-f68.google.com [209.85.161.68]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) 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 49NNGL2h3hz3NBC; Thu, 14 May 2020 20:20:58 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-oo1-f68.google.com with SMTP id i9so1015434ool.5; Thu, 14 May 2020 13:20:58 -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=XATE2oJ0HCuFXl80aMe5Q5Rja4dYj+iHGk3WbqQ5L5k=; b=OckIhjHn8hBzYYAVjFfYj2zlSWONwsdA1bjqyew2cfzDgvp2EDEp+FUCHr0PhqHGAc en6/1W9sIQJ33sUd4IG3dFD6k1VWFU2xRmM5Ac5QPKxNlHMZv18Oiq9qJqM7zOMjcftw GcW/knHtMuYVfYm7jKYxQUCMaxqqty+tbo3U0jeWuSTl09LdnbAyxtEAq45dVVuAwzQD ftbNu9HeZAMCn4lA3PuyVDRmwgmId26BSVObsnIFepyDHkHqSViB0UoWZI6nppSMiuhS xJxZylIsMvJEo3qdPIZeRHWGBKo8Kh6mu+wE+73x7avzumTPR5iNQ0M959Yz0BYO8rCL IVpA== X-Gm-Message-State: AOAM531kWZYQPs+cBxLuVLjXdEocpAH7qKE0HGCTjR1xCjt5OaBEjWaE AfmULX0+06qipATAn5RsdY//kuRS49mjlBu3uIYV1+p0 X-Google-Smtp-Source: ABdhPJz1oesoJ2TL0mvKnDzjdg2rT79hMVCT4EGOe2ig/T0QTHbmsRLXhCsYR6R04mPt9AarDhQxnYThlENR1O1X4io= X-Received: by 2002:a4a:3107:: with SMTP id k7mr5037283ooa.61.1589487657049; Thu, 14 May 2020 13:20:57 -0700 (PDT) MIME-Version: 1.0 References: <202005142017.04EKH0aA093503@fire.js.berklix.net> In-Reply-To: <202005142017.04EKH0aA093503@fire.js.berklix.net> From: Alan Somers Date: Thu, 14 May 2020 14:20:45 -0600 Message-ID: Subject: Re: [HEADSUP] Disallowing read() of a directory fd To: "Julian H. Stacey" Cc: Kyle Evans , "freebsd-arch@freebsd.org" , "freebsd-hackers@freebsd.org" X-Rspamd-Queue-Id: 49NNGL2h3hz3NBC X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.161.68 as permitted sender) smtp.mailfrom=asomers@gmail.com X-Spamd-Result: default: False [-0.89 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; NEURAL_HAM_LONG(-0.95)[-0.947,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-0.67)[-0.670,0]; TO_DN_SOME(0.00)[]; URI_COUNT_ODD(1.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[68.161.85.209.list.dnswl.org : 127.0.5.0]; RWL_MAILSPIKE_GOOD(0.00)[68.161.85.209.rep.mailspike.net : 127.0.0.18]; IP_SCORE(-0.28)[ip: (-0.51), ipnet: 209.85.128.0/17(-0.39), asn: 15169(-0.42), country: US(-0.05)]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2020 20:20:59 -0000 On Thu, May 14, 2020 at 2:17 PM Julian H. Stacey wrote: > Kyle Evans wrote: > > Hi, > > > > This is a heads up, given that I'm completely flipping our historical > > behavior- I intend to commit this review in a couple days' time > > without substantial objection: https://reviews.freebsd.org/D24596 > > > > With this, FreeBSD 13 will not allow read() of a directory fd, which > > could have previously returned some data from the underlying > > filesystem in no particular standardized format. > > > > This is a still-standards-compliant switch from one > > implementation-defined behavior to another that's already been adopted > > in various other popular kernels, to include OpenBSD, MacOS, and > > Linux. > > > > Worth noting is that there's not really one largely-compelling reasons > > to switch this after so many years (unless you find yourself that > > irate when you accidentally `cat` a directory), but there are some > > benefits which are briefly discussed in the commentary around the > > review along with the history of the current behavior. > > > > This change also simplifies filesystem implementations to some extent. > > > > Thanks, > > > > Kyle Evans > > There is ZERO need for a spurious change at 2 days notice after 42+ years ! > > "cat ." as been supported since Unix V6 1978 or earlier, > no problem, even occasionaly useful. > Really? When is that occasionally useful? I've never seen anything useful come out of reading a directory. From owner-freebsd-hackers@freebsd.org Thu May 14 20:23:07 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D8D902DE426 for ; Thu, 14 May 2020 20:23:07 +0000 (UTC) (envelope-from arne@Steinkamm.COM) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 49NNJq3QqLz3Ncq for ; Thu, 14 May 2020 20:23:07 +0000 (UTC) (envelope-from arne@Steinkamm.COM) Received: by mailman.nyi.freebsd.org (Postfix) id 757B02DE424; Thu, 14 May 2020 20:23:07 +0000 (UTC) Delivered-To: hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 752DE2DE422; Thu, 14 May 2020 20:23:07 +0000 (UTC) (envelope-from arne@Steinkamm.COM) Received: from mail.steinkamm.com (mail.steinkamm.com [194.127.175.194]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "steinkamm.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49NNJp0SXnz3Ncp; Thu, 14 May 2020 20:23:05 +0000 (UTC) (envelope-from arne@Steinkamm.COM) Received: from trajan.stk.cx (trajan.stk.cx [10.8.8.110]) by basis.steinkamm.com (8.15.2/8.15.2) with ESMTPS id 04EKMsNZ000970 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Thu, 14 May 2020 22:22:54 +0200 (CEST) (envelope-from arne@steinkamm.com) Received: from trajan.stk.cx (localhost [127.0.0.1]) by trajan.stk.cx (8.15.2/8.15.2) with ESMTPS id 04EKMp7o036258 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 14 May 2020 22:22:51 +0200 (CEST) (envelope-from arne@trajan.stk.cx) Received: (from arne@localhost) by trajan.stk.cx (8.15.2/8.15.2/Submit) id 04EKMoYH036081; Thu, 14 May 2020 22:22:50 +0200 (CEST) (envelope-from arne) Date: Thu, 14 May 2020 22:22:50 +0200 From: Arne Steinkamm To: "Julian H. Stacey" Cc: Kyle Evans , "freebsd-arch@freebsd.org" , hackers@freebsd.org, arne@steinkamm.com Subject: Re: [HEADSUP] Disallowing read() of a directory fd Message-ID: <20200514202250.GS82984@trajan.stk.cx> Reply-To: arne@Steinkamm.COM References: <202005142017.04EKH0aA093503@fire.js.berklix.net> MIME-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <202005142017.04EKH0aA093503@fire.js.berklix.net> User-Agent: Mutt@Trajan/1.12.1 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on basis.steinkamm.com X-Rspamd-Queue-Id: 49NNJp0SXnz3Ncp X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of arne@Steinkamm.COM has no SPF policy when checking 194.127.175.194) smtp.mailfrom=arne@Steinkamm.COM X-Spamd-Result: default: False [1.73 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; HAS_REPLYTO(0.00)[arne@Steinkamm.COM]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.07)[-0.072,0]; IP_SCORE(-0.00)[country: DE(-0.02)]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[Steinkamm.COM]; REPLYTO_DOM_EQ_FROM_DOM(0.00)[]; AUTH_NA(1.00)[]; RCPT_COUNT_FIVE(0.00)[5]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.61)[0.610,0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[freebsd-hackers@Steinkamm.COM,arne@Steinkamm.COM]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:34646, ipnet:194.127.175.0/24, country:DE]; FROM_NEQ_ENVFROM(0.00)[freebsd-hackers@Steinkamm.COM,arne@Steinkamm.COM]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2020 20:23:07 -0000 On Thu, May 14, 2020 at 10:17:00PM +0200, Julian H. Stacey wrote: > > "cat ." as been supported since Unix V6 1978 or earlier, > no problem, even occasionaly useful. > > Most FreeBSD users wont have heard of https://reviews.freebsd.org/D24596 > (& there's only 5 other people's opinions there, apart from proposer, > & skimming through the impression is far from un-qualified approval. > > kevans@ issued arch@ just a couple days notice of intention to commit. > arch@ is also not widely read, ( I jhs@ added CC hackers@) +1 !!! .//. Arne -- Arne Steinkamm | Home: Mail: arnesteinkammcom Tel.: +49.89.21031004 | Gröbenbachweg 13, 82178 Puchheim, GERMANY From owner-freebsd-hackers@freebsd.org Thu May 14 20:30:31 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C2F7C2DE80A for ; Thu, 14 May 2020 20:30:31 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 49NNTL4XvHz3P2W for ; Thu, 14 May 2020 20:30:30 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: by mailman.nyi.freebsd.org (Postfix) id 9BB912DE807; Thu, 14 May 2020 20:30:30 +0000 (UTC) Delivered-To: hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 9B6B92DE806; Thu, 14 May 2020 20:30:30 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49NNTL38M2z3P2V; Thu, 14 May 2020 20:30:29 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (v-critter.freebsd.dk [192.168.55.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by phk.freebsd.dk (Postfix) with ESMTPS id A1E181AF18C; Thu, 14 May 2020 20:30:27 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.15.2/8.15.2) with ESMTPS id 04EKURnS033551 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 14 May 2020 20:30:27 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.15.2/8.15.2/Submit) id 04EKUQmj033550; Thu, 14 May 2020 20:30:26 GMT (envelope-from phk) To: Alan Somers cc: "Julian H. Stacey" , Kyle Evans , "freebsd-arch@freebsd.org" , "freebsd-hackers@freebsd.org" Subject: Re: [HEADSUP] Disallowing read() of a directory fd In-reply-to: From: "Poul-Henning Kamp" References: <202005142017.04EKH0aA093503@fire.js.berklix.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <33548.1589488226.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Thu, 14 May 2020 20:30:26 +0000 Message-ID: <33549.1589488226@critter.freebsd.dk> X-Rspamd-Queue-Id: 49NNTL38M2z3P2V X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-5.96 / 15.00]; NEURAL_HAM_MEDIUM(-0.96)[-0.964,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2020 20:30:31 -0000 -------- In message , Alan Somers writes: >Really? When is that occasionally useful? I've never seen anything usef= ul >come out of reading a directory. Two things I have done over the years: Figure out which filenames prevent a enormous but sparse directory from being compacted. Figure out which control characters were in a filename. It might be a good idea to add a override flag on this feature, along the lines of: kern.geom.debugflags=3D0x10 -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= . From owner-freebsd-hackers@freebsd.org Thu May 14 20:32:33 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 0ABCA2DEB48 for ; Thu, 14 May 2020 20:32:33 +0000 (UTC) (envelope-from arne@Steinkamm.COM) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 49NNWh4TD8z3PTk for ; Thu, 14 May 2020 20:32:32 +0000 (UTC) (envelope-from arne@Steinkamm.COM) Received: by mailman.nyi.freebsd.org (Postfix) id 9971D2DEB46; Thu, 14 May 2020 20:32:32 +0000 (UTC) Delivered-To: hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 992042DEB45; Thu, 14 May 2020 20:32:32 +0000 (UTC) (envelope-from arne@Steinkamm.COM) Received: from mail.steinkamm.com (mail.steinkamm.com [194.127.175.194]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "steinkamm.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49NNWh2HgKz3PTg; Thu, 14 May 2020 20:32:32 +0000 (UTC) (envelope-from arne@Steinkamm.COM) Received: from trajan.stk.cx (trajan.stk.cx [10.8.8.110]) by basis.steinkamm.com (8.15.2/8.15.2) with ESMTPS id 04EKUiFj001065 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Thu, 14 May 2020 22:30:44 +0200 (CEST) (envelope-from arne@steinkamm.com) Received: from trajan.stk.cx (localhost [127.0.0.1]) by trajan.stk.cx (8.15.2/8.15.2) with ESMTPS id 04EKUZht078170 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 14 May 2020 22:30:35 +0200 (CEST) (envelope-from arne@trajan.stk.cx) Received: (from arne@localhost) by trajan.stk.cx (8.15.2/8.15.2/Submit) id 04EKUUgD077625; Thu, 14 May 2020 22:30:30 +0200 (CEST) (envelope-from arne) Date: Thu, 14 May 2020 22:30:30 +0200 From: Arne Steinkamm To: Alan Somers Cc: "Julian H. Stacey" , Kyle Evans , "freebsd-arch@freebsd.org" , "freebsd-hackers@freebsd.org" , arne@steinkamm.com Subject: Re: [HEADSUP] Disallowing read() of a directory fd Message-ID: <20200514203030.GT82984@trajan.stk.cx> Reply-To: arne@Steinkamm.COM References: <202005142017.04EKH0aA093503@fire.js.berklix.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt@Trajan/1.12.1 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on basis.steinkamm.com X-Rspamd-Queue-Id: 49NNWh2HgKz3PTg X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-5.96 / 15.00]; NEURAL_HAM_MEDIUM(-0.96)[-0.964,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2020 20:32:33 -0000 On Thu, May 14, 2020 at 02:20:45PM -0600, Alan Somers wrote: > On Thu, May 14, 2020 at 2:17 PM Julian H. Stacey wrote: > > > Kyle Evans wrote: > > > Hi, > > > > > > This is a heads up, given that I'm completely flipping our historical > > > behavior- I intend to commit this review in a couple days' time > > > without substantial objection: https://reviews.freebsd.org/D24596 > > > > > > With this, FreeBSD 13 will not allow read() of a directory fd, which > > > could have previously returned some data from the underlying > > > filesystem in no particular standardized format. > > > > > > This is a still-standards-compliant switch from one > > > implementation-defined behavior to another that's already been adopted > > > in various other popular kernels, to include OpenBSD, MacOS, and > > > Linux. > > > > > > Worth noting is that there's not really one largely-compelling reasons > > > to switch this after so many years (unless you find yourself that > > > irate when you accidentally `cat` a directory), but there are some > > > benefits which are briefly discussed in the commentary around the > > > review along with the history of the current behavior. > > > > > > This change also simplifies filesystem implementations to some extent. > > > > > > Thanks, > > > > > > Kyle Evans > > > > There is ZERO need for a spurious change at 2 days notice after 42+ years ! > > > > "cat ." as been supported since Unix V6 1978 or earlier, > > no problem, even occasionaly useful. > > > > Really? When is that occasionally useful? I've never seen anything useful > come out of reading a directory. It's all about files in Unix... This is true since 1972. And files can be read! How many (bad programmed) shell scripts will break when directory files can't be read anymore? I have no idea. But I know for sure that there is no need to make this change. Not 1976, not 2020 nor in the future. .//. Arne -- Arne Steinkamm | Home: Mail: arnesteinkammcom From owner-freebsd-hackers@freebsd.org Thu May 14 20:46:27 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 71B092DF43D for ; Thu, 14 May 2020 20:46:27 +0000 (UTC) (envelope-from pjfloyd@wanadoo.fr) Received: from smtp.smtpout.orange.fr (smtp09.smtpout.orange.fr [80.12.242.131]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "Bizanga Labs SMTP Client Certificate", Issuer "Bizanga Labs CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 49NNqj2SdDz3QWZ for ; Thu, 14 May 2020 20:46:24 +0000 (UTC) (envelope-from pjfloyd@wanadoo.fr) Received: from wwinf1n11 ([10.223.72.54]) by mwinf5d69 with ME id ekmM2200S1AGQpE03kmMec; Thu, 14 May 2020 22:46:21 +0200 X-ME-Helo: wwinf1n11 X-ME-Auth: cGpmbG95ZEB3YW5hZG9vLmZy X-ME-Date: Thu, 14 May 2020 22:46:21 +0200 X-ME-IP: 2.7.113.176 Date: Thu, 14 May 2020 22:46:21 +0200 (CEST) From: Paul FLOYD Reply-To: Paul FLOYD To: freebsd-hackers@freebsd.org Message-ID: <490544208.11847.1589489181927.JavaMail.www@wwinf1n11> In-Reply-To: <2102917207.11671.1589487524169.JavaMail.www@wwinf1n11> References: <2102917207.11671.1589487524169.JavaMail.www@wwinf1n11> Subject: re: SIGBUS si_code 12 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [2.7.113.176] X-WUM-FROM: |~| X-WUM-TO: |~| X-WUM-REPLYTO: |~| X-Rspamd-Queue-Id: 49NNqj2SdDz3QWZ X-Spamd-Bar: +++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of pjfloyd@wanadoo.fr has no SPF policy when checking 80.12.242.131) smtp.mailfrom=pjfloyd@wanadoo.fr X-Spamd-Result: default: False [3.37 / 15.00]; HAS_REPLYTO(0.00)[pjfloyd@wanadoo.fr]; HAS_XOIP(0.00)[]; FREEMAIL_FROM(0.00)[wanadoo.fr]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:3215, ipnet:80.12.240.0/20, country:FR]; IP_SCORE(0.00)[ip: (2.66), ipnet: 80.12.240.0/20(1.72), asn: 3215(2.40), country: FR(-0.00)]; FREEMAIL_ENVFROM(0.00)[wanadoo.fr]; ARC_NA(0.00)[]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_REPLYTO(0.00)[wanadoo.fr]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.97)[0.968,0]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE_FREEMAIL(0.00)[]; MIME_TRACE(0.00)[0:+]; NEURAL_SPAM_LONG(1.00)[1.000,0]; RCVD_IN_DNSWL_NONE(0.00)[131.242.12.80.list.dnswl.org : 127.0.5.0]; R_SPF_NA(0.00)[]; DMARC_NA(0.00)[wanadoo.fr]; RWL_MAILSPIKE_POSSIBLE(0.00)[131.242.12.80.rep.mailspike.net : 127.0.0.17]; MID_RHS_NOT_FQDN(0.50)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2020 20:46:27 -0000 Hmm. Looking at the 12.1-stable siginfo manpage this seems to be fixed SIGBUS BUS_ADRALN invalid address alignment BUS_ADRERR nonexistent physical address BUS_OBJERR object-specific hardware error BUS_OOMERR cannot alloc a page to map at fault with this being added to signal.h #define BUS_OOMERR 100 /* Non-standard: No memory. */ So presumably this will go away in 12.2. A+ Paul From owner-freebsd-hackers@freebsd.org Thu May 14 22:19:24 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B539B2E205F for ; Thu, 14 May 2020 22:19:24 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 49NQv02GY5z41sh for ; Thu, 14 May 2020 22:19:24 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: by mailman.nyi.freebsd.org (Postfix) id 4DC8A2E205D; Thu, 14 May 2020 22:19:24 +0000 (UTC) Delivered-To: hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 4D7C72E205B; Thu, 14 May 2020 22:19:24 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ultimatedns.net", Issuer "Let's Encrypt Authority X3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 49NQtz6H4Jz41sg; Thu, 14 May 2020 22:19:23 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (localhost [IPv6:0:0:0:0:0:0:0:1]) by udns.ultimatedns.net (8.15.2/8.15.2) with ESMTPS id 04EMJXOq044241 (version=TLSv1.2 cipher=DHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 14 May 2020 15:19:40 -0700 (PDT) (envelope-from bsd-lists@BSDforge.com) X-Mailer: Cypht MIME-Version: 1.0 Cc: "freebsd-arch@freebsd.org" , , Kyle Evans In-Reply-To: <202005142017.04EKH0aA093503@fire.js.berklix.net> From: Chris Reply-To: bsd-lists@BSDforge.com To: "Julian H. Stacey" Subject: Re: [HEADSUP] Disallowing read() of a directory fd Date: Thu, 14 May 2020 15:19:39 -0700 Message-Id: <1a951a29e3ca52c0ebd823f4a4437412@udns.ultimatedns.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 49NQtz6H4Jz41sg X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-1.09 / 15.00]; NEURAL_HAM_MEDIUM(-0.13)[-0.129,0]; NEURAL_HAM_LONG(-0.96)[-0.962,0]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US]; local_wl_ip(0.00)[24.113.41.81] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2020 22:19:24 -0000 On Thu, 14 May 2020 22:17:00 +0200 Julian H=2E Stacey jhs@berklix=2Ecom said > Kyle Evans wrote: > > Hi, > >=20 > > This is a heads up, given that I'm completely flipping our historical > > behavior- I intend to commit this review in a couple days' time > > without substantial objection: https://reviews=2Efreebsd=2Eorg/D24596 > >=20 > > With this, FreeBSD 13 will not allow read() of a directory fd, which > > could have previously returned some data from the underlying > > filesystem in no particular standardized format=2E > >=20 > > This is a still-standards-compliant switch from one > > implementation-defined behavior to another that's already been adopted > > in various other popular kernels, to include OpenBSD, MacOS, and > > Linux=2E Completely different file systems=2E This is a non-reason/excuse to impose such a change=2E > >=20 > > Worth noting is that there's not really one largely-compelling reasons > > to switch this after so many years (unless you find yourself that > > irate when you accidentally `cat` a directory), but there are some > > benefits which are briefly discussed in the commentary around the > > review along with the history of the current behavior=2E > >=20 > > This change also simplifies filesystem implementations to some extent=2E > >=20 > > Thanks, > >=20 > > Kyle Evans >=20 > There is ZERO need for a spurious change at 2 days notice after 42+ years= ! +2! >=20 > "cat =2E" as been supported since Unix V6 1978 or earlier,=20 > no problem, even occasionaly useful=2E >=20 > Most FreeBSD users wont have heard of https://reviews=2Efreebsd=2Eorg/D24596 > (& there's only 5 other people's opinions there, apart from proposer, > & skimming through the impression is far from un-qualified approval=2E >=20 >=20 > Do not force all FreeBSD users towards gratuitous change for personal > preference for Linux behaviour=2E Switch to Linux, Or hack a > personalised shell on BSD that does what you want when you type > "cat =2E" If it's later widely popular, use it as proof to re-propose=2E No > Rush=2E This bikeshed is already the correct color=2E Please leave it as is=2E >=20 > A bigger issue is due notice procedure, & respect to FreeBSD stability of > code > & users expectations of predictability=2E > Unwarned playing about would detract from FreeBSD's business image=2E Amen to that=2E >=20 > Cheers > -- > Julian Stacey, Consultant Systems Engineer, BSD Linux > http://berklix=2Ecom/jhs/ > http://www=2Eberklix=2Eorg/corona/#masks Tie 2 handkerchiefs or 1 pillow cas= e=2E=20 > Jobs & economy hit by Corona to be hit again by Crash Brexit 31st Dec=2E 20= 20 --Chris From owner-freebsd-hackers@freebsd.org Thu May 14 22:43:56 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 6BA872E2B20 for ; Thu, 14 May 2020 22:43:56 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49NRRH0Yyrz43Fg for ; Thu, 14 May 2020 22:43:54 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id 04EMhlwp009659 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 15 May 2020 01:43:51 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 04EMhlwp009659 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id 04EMhlBe009658; Fri, 15 May 2020 01:43:47 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 15 May 2020 01:43:47 +0300 From: Konstantin Belousov To: Paul FLOYD Cc: freebsd-hackers@freebsd.org Subject: Re: SIGBUS si_code 12 Message-ID: <20200514224347.GB46537@kib.kiev.ua> References: <2102917207.11671.1589487524169.JavaMail.www@wwinf1n11> <490544208.11847.1589489181927.JavaMail.www@wwinf1n11> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <490544208.11847.1589489181927.JavaMail.www@wwinf1n11> X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on tom.home X-Rspamd-Queue-Id: 49NRRH0Yyrz43Fg X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kostikbel@gmail.com) smtp.mailfrom=kostikbel@gmail.com X-Spamd-Result: default: False [-2.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all:c]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; IP_SCORE(0.00)[ip: (-3.07), ipnet: 2001:470::/32(-4.10), asn: 6939(-3.15), country: US(-0.05)]; FREEMAIL_TO(0.00)[wanadoo.fr]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2020 22:43:56 -0000 On Thu, May 14, 2020 at 10:46:21PM +0200, Paul FLOYD wrote: > Hmm. Looking at the 12.1-stable siginfo manpage this seems to be fixed > > SIGBUS BUS_ADRALN invalid address alignment > BUS_ADRERR nonexistent physical address > BUS_OBJERR object-specific hardware error > BUS_OOMERR cannot alloc a page to map at fault > > with this being added to signal.h > > #define BUS_OOMERR 100 /* Non-standard: No memory. */ > > So presumably this will go away in 12.2. I do not understand what do you mean. What should go away ? Also, T_PAGEFLT value for si_code is a compat value that should be explicitly enabled by user, for compatibility with some really old binaries. From owner-freebsd-hackers@freebsd.org Thu May 14 22:50:03 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 40B4F2E2CAA for ; Thu, 14 May 2020 22:50:03 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 49NRZM13Fbz43RK for ; Thu, 14 May 2020 22:50:03 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 222CC2E2CA8; Thu, 14 May 2020 22:50:03 +0000 (UTC) Delivered-To: hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 20C932E2CA7; Thu, 14 May 2020 22:50:03 +0000 (UTC) (envelope-from kevans@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) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49NRZL75pJz43RH; Thu, 14 May 2020 22:50:02 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-qk1-f174.google.com (mail-qk1-f174.google.com [209.85.222.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id E32DC122E6; Thu, 14 May 2020 22:50:02 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qk1-f174.google.com with SMTP id f83so603000qke.13; Thu, 14 May 2020 15:50:02 -0700 (PDT) X-Gm-Message-State: AOAM533hUdXNWDW6onAueCqLQLy1iLjAFHyZbi1vhKaOMFniPLnejoWB AVHoj/3Irci87fZGWgjXyO3lBNWbeW7g44y2sh8= X-Google-Smtp-Source: ABdhPJyfSUheNEGsNaaPEaIpnrpg2PedS3yTVInniLBJCIqGkIoYi/UZLHkGPyp5Imu2ahHT/06wpYmDW0oAHlGwNjA= X-Received: by 2002:a37:5b47:: with SMTP id p68mr738238qkb.120.1589496602347; Thu, 14 May 2020 15:50:02 -0700 (PDT) MIME-Version: 1.0 References: <202005142017.04EKH0aA093503@fire.js.berklix.net> In-Reply-To: <202005142017.04EKH0aA093503@fire.js.berklix.net> From: Kyle Evans Date: Thu, 14 May 2020 17:49:51 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [HEADSUP] Disallowing read() of a directory fd To: "Julian H. Stacey" Cc: "freebsd-arch@freebsd.org" , hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2020 22:50:03 -0000 On Thu, May 14, 2020 at 3:17 PM Julian H. Stacey wrote: > > Kyle Evans wrote: > > Hi, > > > > This is a heads up, given that I'm completely flipping our historical > > behavior- I intend to commit this review in a couple days' time > > without substantial objection: https://reviews.freebsd.org/D24596 > > > > With this, FreeBSD 13 will not allow read() of a directory fd, which > > could have previously returned some data from the underlying > > filesystem in no particular standardized format. > > > > This is a still-standards-compliant switch from one > > implementation-defined behavior to another that's already been adopted > > in various other popular kernels, to include OpenBSD, MacOS, and > > Linux. > > > > Worth noting is that there's not really one largely-compelling reasons > > to switch this after so many years (unless you find yourself that > > irate when you accidentally `cat` a directory), but there are some > > benefits which are briefly discussed in the commentary around the > > review along with the history of the current behavior. > > > > This change also simplifies filesystem implementations to some extent. > > > > Thanks, > > > > Kyle Evans > > There is ZERO need for a spurious change at 2 days notice after 42+ years ! > Sorry, this was a sloppy wording/prediction. There's no way I would have gotten to committing it before Tuesday, even, with how overcommitted I am between FreeBSD and the physical world around me. > "cat ." as been supported since Unix V6 1978 or earlier, > no problem, even occasionaly useful. > Do you have examples? The entire point of this thread is to solicit valid complaints from 'the other side.' > Most FreeBSD users wont have heard of https://reviews.freebsd.org/D24596 > (& there's only 5 other people's opinions there, apart from proposer, > & skimming through the impression is far from un-qualified approval. > > kevans@ issued arch@ just a couple days notice of intention to commit. > arch@ is also not widely read, ( I jhs@ added CC hackers@) > > Many FreeBSD end users won't even be reading hackers@ (some not > even announce@,) & would notice just yet another pointless change > sometime after upgrade. > Sure- it's hard to know just how many lists to cross-post to. Thanks for adding -hackers@. > Do not force all FreeBSD users towards gratuitous change for personal > preference for Linux behaviour. Switch to Linux, Or hack a > personalised shell on BSD that does what you want when you type > "cat ." If it's later widely popular, use it as proof to re-propose. No Rush. > Suggestions like this are wholly unwelcome. If I wanted Linux semantics, I would instead hack on Linux and ditch FreeBSD entirely. I can weave together a Linux + BSD userland if that's really what I wanted, but alas- it's not. I want sane and consistent semantics here, given that most of our filesystems either already return EISDIR or just return some garbage that maybe resembles something useful to someone (e.g. ZFS, where it's not even clear that it was intended to allow vop_read of a dir). To a degree I also want to no longer fix application bugs because they assume here the implementation-defined semantics that almost the rest of the world has already opted for (again, at least OpenBSD, MacOS, Linux). Such bugs have wasted a lot of my already sparse time because they're not always trivial to identify, and the reward for keeping this around is almost nonexistent for most users of FreeBSD, a very large chunk of which run filesystems where `cat .` doesn't produce any meaningful data. Thanks, Kyle Evans From owner-freebsd-hackers@freebsd.org Thu May 14 22:56:09 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 9D8A32E3266 for ; Thu, 14 May 2020 22:56:09 +0000 (UTC) (envelope-from mail@ozzmosis.com) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 49NRjP30YKz440W for ; Thu, 14 May 2020 22:56:09 +0000 (UTC) (envelope-from mail@ozzmosis.com) Received: by mailman.nyi.freebsd.org (Postfix) id 66BC72E3265; Thu, 14 May 2020 22:56:09 +0000 (UTC) Delivered-To: hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 6680A2E3264 for ; Thu, 14 May 2020 22:56:09 +0000 (UTC) (envelope-from mail@ozzmosis.com) Received: from relay2-d.mail.gandi.net (relay2-d.mail.gandi.net [217.70.183.194]) (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 49NRjN2vHZz440V for ; Thu, 14 May 2020 22:56:08 +0000 (UTC) (envelope-from mail@ozzmosis.com) X-Originating-IP: 167.179.139.56 Received: from blizzard.ozzmosis.com (167-179-139-56.a7b38b.mel.nbn.aussiebb.net [167.179.139.56]) (Authenticated sender: ozzmosis@ozzmosis.com) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id 1FDBC40003; Thu, 14 May 2020 22:56:05 +0000 (UTC) Received: by blizzard.ozzmosis.com (Postfix, from userid 1001) id 49FAB51B85; Fri, 15 May 2020 08:56:01 +1000 (AEST) Date: Fri, 15 May 2020 08:56:01 +1000 From: andrew clarke To: "Julian H. Stacey" Cc: hackers@freebsd.org Subject: Re: [HEADSUP] Disallowing read() of a directory fd Message-ID: <20200514225601.o427xiucy67reh4x@ozzmosis.com> References: <202005142017.04EKH0aA093503@fire.js.berklix.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <202005142017.04EKH0aA093503@fire.js.berklix.net> User-Agent: NeoMutt/20200501 X-Rspamd-Queue-Id: 49NRjN2vHZz440V X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of mail@ozzmosis.com designates 217.70.183.194 as permitted sender) smtp.mailfrom=mail@ozzmosis.com X-Spamd-Result: default: False [-3.51 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_XOIP(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:217.70.183.192/28:c]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[ozzmosis.com]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; RWL_MAILSPIKE_GOOD(0.00)[194.183.70.217.rep.mailspike.net : 127.0.0.18]; RCVD_IN_DNSWL_LOW(-0.10)[194.183.70.217.list.dnswl.org : 127.0.5.1]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; IP_SCORE(-1.11)[ip: (-2.64), ipnet: 217.70.176.0/20(-1.61), asn: 29169(-1.29), country: FR(-0.00)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:29169, ipnet:217.70.176.0/20, country:FR]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2020 22:56:09 -0000 On 2020-05-14 22:17:00, Julian H. Stacey (jhs@berklix.com) wrote: > There is ZERO need for a spurious change at 2 days notice after 42+ years ! > > "cat ." as been supported since Unix V6 1978 or earlier, > no problem, even occasionaly useful. I think you're overstating its importance. In the past I've accidentally run "cat" on a directory in FreeBSD and was surprised it didn't return an error. Running "cat /" here on FreeBSD 12.1-REL results in no useful output, perhaps because root is on ZFS: $ cat / | hd 00000000 03 00 00 00 00 00 00 80 19 a5 bc 00 00 00 00 00 |................| 00000010 00 00 00 00 00 00 00 00 00 00 00 00 |............| 0000001c So I have no problem with "cat /" returning a more useful error message instead. From owner-freebsd-hackers@freebsd.org Fri May 15 05:10:46 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id CA1712EA2B6 for ; Fri, 15 May 2020 05:10:46 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 49Nc1f54H6z4Mcj for ; Fri, 15 May 2020 05:10:46 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id ABE132EA2B3; Fri, 15 May 2020 05:10:46 +0000 (UTC) Delivered-To: hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id A96AF2EA2B2; Fri, 15 May 2020 05:10:46 +0000 (UTC) (envelope-from kevans@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) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49Nc1f3s2Sz4Mch; Fri, 15 May 2020 05:10:46 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-qk1-f178.google.com (mail-qk1-f178.google.com [209.85.222.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 7267D15081; Fri, 15 May 2020 05:10:46 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qk1-f178.google.com with SMTP id n14so1356505qke.8; Thu, 14 May 2020 22:10:46 -0700 (PDT) X-Gm-Message-State: AOAM5330gz+2qtY2QcG8BIQCVcafJhyb9fbxOltEXeiVeFziQBbnCLTC oi1UOC5o6S/1kkvXlUDh6Dcmjx/+7TQVSHGzgC0= X-Google-Smtp-Source: ABdhPJwEHWGNVqdxTqk+9EMmeY/wUZXSzJq9hkYFicsfGqLgP8PnKIIAvYac7WuBarCS4TKGJo5w8xOK3B9YkwqeQ7A= X-Received: by 2002:a37:8c4:: with SMTP id 187mr1770425qki.34.1589519446067; Thu, 14 May 2020 22:10:46 -0700 (PDT) MIME-Version: 1.0 References: <202005142017.04EKH0aA093503@fire.js.berklix.net> <33549.1589488226@critter.freebsd.dk> In-Reply-To: <33549.1589488226@critter.freebsd.dk> From: Kyle Evans Date: Fri, 15 May 2020 00:10:35 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [HEADSUP] Disallowing read() of a directory fd To: Poul-Henning Kamp Cc: Alan Somers , "Julian H. Stacey" , "freebsd-arch@freebsd.org" , "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 05:10:46 -0000 On Thu, May 14, 2020 at 3:30 PM Poul-Henning Kamp wrote: > > -------- > In message > , Alan Somers writes: > > >Really? When is that occasionally useful? I've never seen anything useful > >come out of reading a directory. > > Two things I have done over the years: > > Figure out which filenames prevent a enormous but sparse directory > from being compacted. > > Figure out which control characters were in a filename. > Can we explore the possibility of using fsdb(8) to fulfill these needs in a way that you'd be comfortable with? I am thoroughly motivated and willing to do what I can to find a good path forward. We could add a sysctl and remove the functionality from other filesystems that aren't necessarily providing useful information and likely haven't been audited for similar disclosures to https://www.freebsd.org/security/advisories/FreeBSD-SA-19:10.ufs.asc that may be exacerbated by read(2) on a dirfd, but I'd like to see if there's any compromise that we can make where the compromise on my side is that I have to put in the effort to otherwise enable presented valid use-cases in an agreeable manner. Is there anything that I, as a developer that knows very little about UFS and even less when compared to someone such as yourself, can do to facilitate making this as easy as possible with the tooling otherwise available? Looking at fsdb(8) briefly on this UFS partition I just spun up, it seems as a somewhat low-hanging fruit that we could (in some/many cases) infer a disk device from a standard directory/file path and prompt for confirmation based on that, opening up to the proper inode, even, as an example (wording would differ, and apologies for the formatting): root@shiva:/mnt# stat etc 682 12928 drwxr-xr-x 2 root wheel 26456 512 "May 14 23:58:27 2020" "May 14 23:58:27 2020" "May 14 23:58:27 2020" "May 14 23:58:27 2020" 32768 8 0 etc root@shiva:/mnt# fsdb etc etc is not a disk device, but is mounted from /dev/md1. Use /dev/md1? [yn] y ** /dev/md1 (NO WRITE) Editing file system `/dev/md1' Last Mounted on /mnt current inode: directory I=12928 MODE=40755 SIZE=512 BTIME=May 14 23:58:27 2020 [611088000 nsec] MTIME=May 14 23:58:27 2020 [614391000 nsec] CTIME=May 14 23:58:27 2020 [614391000 nsec] ATIME=May 14 23:58:27 2020 [614391000 nsec] OWNER=root GRP=wheel LINKCNT=2 FLAGS=0 BLKCNT=8 GEN=a15cce24 fsdb (inum: 12928)> ls slot 0 off 0 ino 12928 reclen 12: directory, `.' slot 1 off 12 ino 2 reclen 500: directory, `..' fsdb (inum: 12928)> Thanks, Kyle Evans From owner-freebsd-hackers@freebsd.org Fri May 15 06:35:58 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 009942EBDC9 for ; Fri, 15 May 2020 06:35:57 +0000 (UTC) (envelope-from pjfloyd@wanadoo.fr) Received: from smtp.smtpout.orange.fr (smtp06.smtpout.orange.fr [80.12.242.128]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "Bizanga Labs SMTP Client Certificate", Issuer "Bizanga Labs CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 49Ndvw2s34z4RLF for ; Fri, 15 May 2020 06:35:55 +0000 (UTC) (envelope-from pjfloyd@wanadoo.fr) Received: from garrigue.home ([2.7.113.176]) by mwinf5d11 with ME id eubt2200F3oQd2y03ubtux; Fri, 15 May 2020 08:35:53 +0200 X-ME-Helo: garrigue.home X-ME-Auth: cGpmbG95ZEB3YW5hZG9vLmZy X-ME-Date: Fri, 15 May 2020 08:35:53 +0200 X-ME-IP: 2.7.113.176 From: Paul Floyd Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: SIGBUS si_code 12 Date: Fri, 15 May 2020 08:35:53 +0200 References: <2102917207.11671.1589487524169.JavaMail.www@wwinf1n11> <490544208.11847.1589489181927.JavaMail.www@wwinf1n11> <20200514224347.GB46537@kib.kiev.ua> To: FreeBSD Hackers In-Reply-To: <20200514224347.GB46537@kib.kiev.ua> Message-Id: <9840EA0E-CF11-4332-A5A0-A3CDBA0F0464@wanadoo.fr> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 49Ndvw2s34z4RLF X-Spamd-Bar: +++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of pjfloyd@wanadoo.fr has no SPF policy when checking 80.12.242.128) smtp.mailfrom=pjfloyd@wanadoo.fr X-Spamd-Result: default: False [3.38 / 15.00]; FREEMAIL_FROM(0.00)[wanadoo.fr]; MV_CASE(0.50)[]; TO_DN_ALL(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[176.113.7.2.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[wanadoo.fr]; ASN(0.00)[asn:3215, ipnet:80.12.240.0/20, country:FR]; MID_RHS_MATCH_FROM(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.00)[ip: (2.44), ipnet: 80.12.240.0/20(1.72), asn: 3215(2.39), country: FR(-0.00)]; DMARC_NA(0.00)[wanadoo.fr]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_SPAM_MEDIUM(0.98)[0.983,0]; RCVD_TLS_LAST(0.00)[]; NEURAL_SPAM_LONG(1.00)[1.000,0]; RCVD_IN_DNSWL_NONE(0.00)[128.242.12.80.list.dnswl.org : 127.0.5.0]; R_SPF_NA(0.00)[]; IP_SCORE_FREEMAIL(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[128.242.12.80.rep.mailspike.net : 127.0.0.17]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 06:35:58 -0000 > On 15 May 2020, at 00:43, Konstantin Belousov = wrote: >=20 >>=20 >>=20 >> So presumably this will go away in 12.2. > I do not understand what do you mean. What should go away ? >=20 > Also, T_PAGEFLT value for si_code is a compat value that should be > explicitly enabled by user, for compatibility with some really old > binaries. The undocumented behaviour of having a SIGBUS with an si_code that is = normally for SIGSEGV. =46rom what I=E2=80=99ve seen BUS_OOMERR will be used instead. A+ Paul From owner-freebsd-hackers@freebsd.org Fri May 15 07:51:47 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 906822ED2C0 for ; Fri, 15 May 2020 07:51:47 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 49NgbR0mWcz4VdP for ; Fri, 15 May 2020 07:51:47 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: by mailman.nyi.freebsd.org (Postfix) id 1A31B2ED2BC; Fri, 15 May 2020 07:51:47 +0000 (UTC) Delivered-To: hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 18B3B2ED2BB; Fri, 15 May 2020 07:51:47 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49NgbP30b7z4VdH; Fri, 15 May 2020 07:51:44 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (v-critter.freebsd.dk [192.168.55.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by phk.freebsd.dk (Postfix) with ESMTPS id C2E501AF18C; Fri, 15 May 2020 07:51:42 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.15.2/8.15.2) with ESMTPS id 04F7pgrH035503 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 15 May 2020 07:51:42 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.15.2/8.15.2/Submit) id 04F7pgXZ035502; Fri, 15 May 2020 07:51:42 GMT (envelope-from phk) To: Kyle Evans cc: Alan Somers , "Julian H. Stacey" , "freebsd-arch@freebsd.org" , "freebsd-hackers@freebsd.org" Subject: Re: [HEADSUP] Disallowing read() of a directory fd In-reply-to: From: "Poul-Henning Kamp" References: <202005142017.04EKH0aA093503@fire.js.berklix.net> <33549.1589488226@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <35500.1589529102.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Fri, 15 May 2020 07:51:42 +0000 Message-ID: <35501.1589529102@critter.freebsd.dk> X-Rspamd-Queue-Id: 49NgbP30b7z4VdH X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of phk@critter.freebsd.dk designates 130.225.244.222 as permitted sender) smtp.mailfrom=phk@critter.freebsd.dk X-Spamd-Result: default: False [-1.78 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.87)[-0.872,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-0.95)[-0.954,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.dk]; RCPT_COUNT_FIVE(0.00)[5]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; IP_SCORE(0.04)[ip: (0.06), ipnet: 130.225.0.0/16(0.08), asn: 1835(0.08), country: EU(-0.01)]; FORGED_SENDER(0.30)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU]; FROM_NEQ_ENVFROM(0.00)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 07:51:47 -0000 -------- In message , Kyle Evans writes: >On Thu, May 14, 2020 at 3:30 PM Poul-Henning Kamp wr= ote: >Can we explore the possibility of using fsdb(8) to fulfill these needs >in a way that you'd be comfortable with? First, I am perfectly comfortable with fsdb(8), but in both the two scenarios it was much less timeconsuming to do: strings < /some/directory | head Which immediately gives you the first filenames in the directory, without waiting for ls(1) to read the entire directory, which in this case was well north of 100MB. In the other case hexdump -C < /some/directory | grep part_of_suspect_filename gave me the answer faster than I could have started fsdb, it gave me the answer in convenient hexadecimal, and besides it was not = a UFS filesystem. Second, one of the major reasons, probably about 3/4 of the total reason I ended up in FreeBSD, was because of some utterly shit experiences with commercial operating systems, where I had been in a tight corner at 00-dark o'clock, and run straight into something some idiot of at the vendor thought root should not be able to do "for their own safety". This change falls right into that category: If root wants to hexdump a directory, an entire bloody disk, or even if root wants to go and do binary surgery on a mounted file system with a hex-editor, root should be able to do that. She may have to `sysctl kern.warranty_voided=3D999` first, to disable *under normal circumstances* reasonable and sensible protections. I'm perfectly fine with that: We do not want to make being root a minefield, and I myself put the ability to munge mounted filesystems under such a interlock in GEOM. But we should not make it *impossible* to do these things, and in particular, we should not make them require a reboot, because ten times out of nine, when you find yourself doing this kind of shit, it is usually because you're pretty sure everything is lost if you reboot. Summary: I'm perfectly fine with read(2) returning error on a directory *under normal circumstances*, and I think it makes good sense by protecting a lot of terminals from a lot of binary garbage. But there is absolutely no reason to make it *impossible* for a competent root to do what competent roots do. -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= . From owner-freebsd-hackers@freebsd.org Fri May 15 09:47:48 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id BA4262F050D; Fri, 15 May 2020 09:47:48 +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) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49Nk9J4HMHz4bVv; Fri, 15 May 2020 09:47:48 +0000 (UTC) (envelope-from se@freebsd.org) Received: from Stefans-MacBook-Pro-449.fritz.box (p200300CD5F25D600ACFE788A6E98E203.dip0.t-ipconnect.de [IPv6:2003:cd:5f25:d600:acfe:788a:6e98:e203]) (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 23C5618E86; Fri, 15 May 2020 09:47:47 +0000 (UTC) (envelope-from se@freebsd.org) Subject: Re: [HEADSUP] Disallowing read() of a directory fd References: <202005142017.04EKH0aA093503@fire.js.berklix.net> <20200514203030.GT82984@trajan.stk.cx> <20200515011258.GW82984@trajan.stk.cx> From: =?UTF-8?Q?Stefan_E=c3=9fer?= Autocrypt: addr=se@freebsd.org; keydata= mQENBFVxiRIBCADOLNOZBsqlplHUQ3tG782FNtVT33rQli9EjNt2fhFERHIo4NxHlWBpHLnU b0s4L/eItx7au0i7Gegv01A9LUMwOnAc9EFAm4EW3Wmoa6MYrcP7xDClohg/Y69f7SNpEs3x YATBy+L6NzWZbJjZXD4vqPgZSDuMcLU7BEdJf0f+6h1BJPnGuwHpsSdnnMrZeIM8xQ8PPUVQ L0GZkVojHgNUngJH6e21qDrud0BkdiBcij0M3TCP4GQrJ/YMdurfc8mhueLpwGR2U1W8TYB7 4UY+NLw0McThOCLCxXflIeF/Y7jSB0zxzvb/H3LWkodUTkV57yX9IbUAGA5RKRg9zsUtABEB AAG0J1N0ZWZhbiBFw59lciAoRnJlZUJTRCkgPHNlQGZyZWVic2Qub3JnPokBVAQTAQoAPgIb AwULCQgHAwUVCgkICwUWAwIBAAIeAQIXgBYhBKNx6mWcC+zIK3FTE0frte9a/fVEBQJa8u+q BQkLJQETAAoJEEfrte9a/fVEOeMH/icmdK1eZQvB3U8quJo9VMaZsaTuCMbUE4NThyfsIvIm MCd+rb/yULmMYwqNfjyKB1x4ikR4x+94l+yJoz7K0Usks+eNKDmMGJM6pWWssTigaJubFdVd hVVC+C1QJi7JshYSib08uONoPmO4lv5Az0TDYGtsMzsES2sIlc62c9go5WPGYhQFRbX3Lk6y V6m8OHh+G9XGSj3oPO4UteRwu+SzTdOLunZBWG1wu34+IeZm663D+2gOppQLWpLa2qaTerqw THu377ayZ2B2LPJ5JkvkZeHYPkwDQ+b5PGn0UhfkxPnDVYki5F7qKxvQ5uq1/q9YaCX7mmOl H2yO7tgVsrW5AQ0EVXGJEgEIALEj9qCXMZVucjpcd3QxM/TlUr98m5viEd1z4tCnPUyRWcIC EVtj2h5xMH+2iB0q1+KWhq+NsWtvScmEmfHnsr7dJ1K677OdpDhKVaJk61eeRulFY1R4yb6C 1MMxK+WgYB+vvpG0UeyR0M4uBewcPvRsq4yGUHFQKtLAbMdoPTSryJA+ElnmK1vdY+rPcHgi OIMBZM7ahsPXC0C9K4e5SP9clGyIoMpbfHXdx9q+Rp3zVtlbhyk3BS/xccu/+9pk9ICXL6GR js2sNnJ0wxdU1DsAlC59a5MnSruwiZFwRnkQhr3x6wk97Lg7sLS9jjTnCN7LGlVmSmpOEMy6 uq1AWfUAEQEAAYkBPAQYAQoAJgIbDBYhBKNx6mWcC+zIK3FTE0frte9a/fVEBQJa8u+rBQkL JQEZAAoJEEfrte9a/fVEuesH/2DNxGWnHvWwMyiyhlQtafvDKwEn/wAgR8gHJFodB7emf8rA TnukH7MVttCoHtjN5lvv9RSBHjNTZls5wR/ANlwdRuPQHd8ZGxLe3S6IuUB3zDSwFltLGurO N2kOMhs5mTGyypSa+uw3rtQbUAVYf1oPbiR4FLtiM8FLyEvE95hX5fPq9Qvx9FmN79kmCIEw jDKPqDaUf/OR2fEF0LSIbXHEk4tNqCEwx5DIJ0fp5/z5UzICUAmwxyRs5O/Hre1jzPsMVyud Ml9t7UTOJGKVWwRory1PMnOFxN+iz5/d4FhYSKXF7kfMiFgol4LuWaxJRwbBrr71VGBrRy2a L1nw6Bc= Cc: freebsd-arch@freebsd.org, FreeBSD Hackers To: Arne Steinkamm Message-ID: Date: Fri, 15 May 2020 11:47:44 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200515011258.GW82984@trajan.stk.cx> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 09:47:48 -0000 Am 15.05.20 um 03:12 schrieb Arne Steinkamm: > On Thu, May 14, 2020 at 02:20:45PM -0600, Alan Somers wrote: >> On Thu, May 14, 2020 at 2:17 PM Julian H. Stacey wrote: >> >>> Kyle Evans wrote: >>>> Hi, >>>> >>>> This is a heads up, given that I'm completely flipping our historical >>>> behavior- I intend to commit this review in a couple days' time >>>> without substantial objection: https://reviews.freebsd.org/D24596 >>>> >>>> With this, FreeBSD 13 will not allow read() of a directory fd, which >>>> could have previously returned some data from the underlying >>>> filesystem in no particular standardized format. >>>> >>>> This is a still-standards-compliant switch from one >>>> implementation-defined behavior to another that's already been adopted >>>> in various other popular kernels, to include OpenBSD, MacOS, and >>>> Linux. >>>> >>>> Worth noting is that there's not really one largely-compelling reasons >>>> to switch this after so many years (unless you find yourself that >>>> irate when you accidentally `cat` a directory), but there are some >>>> benefits which are briefly discussed in the commentary around the >>>> review along with the history of the current behavior. >>>> >>>> This change also simplifies filesystem implementations to some extent. >>>> >>>> Thanks, >>>> >>>> Kyle Evans >>> >>> There is ZERO need for a spurious change at 2 days notice after 42+ years ! >>> >>> "cat ." as been supported since Unix V6 1978 or earlier, >>> no problem, even occasionaly useful. >>> >> >> Really? When is that occasionally useful? I've never seen anything useful >> come out of reading a directory. > > It's all about files in Unix... > > This is true since 1972. > > And files can be read! > > How many (bad programmed) shell scripts will break when directory files can't > be read anymore? I have no idea. And how many shell scripts will break if you migrate from UFS to ZFS which does not return the same data? Reading a directory entry as a byte stream for low level debugging has been the only valid use case I've seen in this thread. And I'm convinced that any developer going to work on that part of UFS would consider adding debug code to provide or display that information (or remove the error return just for local testing) a minor annoyance. > But I know for sure that there is no need to make this change. > Not 1976, not 2020 nor in the future. There might be no need in the strict sense, but some reasons have been provided: - Linux, macOS, OpenBSD do it (not a good reason in itself) - applications developed with Linux or macOS in mind might expect it (and that is a valid reason, IMHO) - currently we make no guarantee with regard to success or failure of reading a directory - it depends on the choice made by the file system (and technical limitations, e.g. in case of NFS) - information could be leaked that is of use to an attacker (and that might have been the main reason it has been prohibited in OpenBSD) Every script run by an unprivileged user ought to be able to deal with a directory that cannot be read e.g. because of insufficient privilege. A script run by root should never depend on unspecified behavior (even if in case that it has been defined behavior in BSD for a long time). I'm convinced that there is more code today that has been developed on Linux and breaks on FreeBSD, unless specifically patched, then there are shell scripts that break when directory access is limited to the access functions provided for this purpose for decades. I've always been a strong supporter of POLA, but do not see how this suggested change is going to be a violation of that principle. We could make this change in -CURRENT, not MFC at all or after a long period of testing whether there is any fall-out, and then decide whether we want it backed out or controller by a tunable or sysctl. Such an experiment in -CURRENT (announced on the appropriate lists) should not cause any trouble or churn for developers and let us find out, if there really is some negative impact. Regards, STefan From owner-freebsd-hackers@freebsd.org Fri May 15 11:14:17 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 58A2A2F2210; Fri, 15 May 2020 11:14:17 +0000 (UTC) (envelope-from debdrup@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49Nm551gRVz3CCw; Fri, 15 May 2020 11:14:17 +0000 (UTC) (envelope-from debdrup@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1471) id 0AC7D17778; Fri, 15 May 2020 11:14:17 +0000 (UTC) Date: Fri, 15 May 2020 13:14:13 +0200 From: Daniel Ebdrup Jensen To: freebsd-arch@freebsd.org, FreeBSD Hackers Subject: Re: [HEADSUP] Disallowing read() of a directory fd Message-ID: <20200515111413.f42c4howkre4btnc@nerd-thinkpad.local> Mail-Followup-To: Daniel Ebdrup Jensen , freebsd-arch@freebsd.org, FreeBSD Hackers References: <202005142017.04EKH0aA093503@fire.js.berklix.net> <20200514203030.GT82984@trajan.stk.cx> <20200515011258.GW82984@trajan.stk.cx> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="mw2ngzz6mbqcpkrd" Content-Disposition: inline In-Reply-To: X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 11:14:17 -0000 --mw2ngzz6mbqcpkrd Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, May 15, 2020 at 11:47:44AM +0200, Stefan E=DFer wrote: >And I'm convinced that any developer going to work on that part of UFS >would consider adding debug code to provide or display that information >(or remove the error return just for local testing) a minor annoyance. >[SNIP] > >Regards, STefan >_______________________________________________ >freebsd-arch@freebsd.org mailing list >https://lists.freebsd.org/mailman/listinfo/freebsd-arch >To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" They could also add tracepoints for dtrace, and commit them to the tree so= =20 everyone can use them. :) Afterall, there's only +82k tracepoints (on FreeBSD 12.1-RELEASE, probably = more=20 in -CURRENT), so there's clearly room for improvement, especially when you = look=20 at the distribution with: dtrace -l | awk '{ print $2 }' | uniq -c | sort -n Yours, Daniel Ebdrup Jensen --mw2ngzz6mbqcpkrd Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAABCgB9FiEEDonNJPbg/JLIMoS6Ps5hSHzN87oFAl6+eYVfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDBF ODlDRDI0RjZFMEZDOTJDODMyODRCQTNFQ0U2MTQ4N0NDREYzQkEACgkQPs5hSHzN 87rujwgAuQKg8Ayh6U2D8oD7IwKEJQf/z6Xtu0JrhgJQ8VbBn2L99+rxT+xnjUnE duTPXCPmc8La3fueZRc3nJ0BDNaZCwyflAb1K87yY4HeJjvGsPS4laULJ6OpQMBe u35NRkMAojEL4CyeSUHEp0kF/qt32DbyDple80bEuI/S0TFcm1CWAmpKmd4qSyiL zpMWNIKarYjb2B9MsyARXQLQv+e/8exvf9w2KKyU7Yc8xHMJvS8/HvMoWhsGrPgZ qLC+Kz/w0fwcD5h5HYzwgr38vf0tykW1NTd4rAKy2sqgVSBW882tFosygrxN50q/ u8DopcJF47hKHBrOSPE5kezN+QOnVA== =GDAv -----END PGP SIGNATURE----- --mw2ngzz6mbqcpkrd-- From owner-freebsd-hackers@freebsd.org Fri May 15 11:48:21 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 42C092F2D5C; Fri, 15 May 2020 11:48:21 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from mail.madpilot.net (vogon.madpilot.net [159.69.1.99]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49NmrM3ZYTz3DjC; Fri, 15 May 2020 11:48:19 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from mail (mail [192.168.254.3]) by mail.madpilot.net (Postfix) with ESMTP id 49NmrD3V77z6dX7; Fri, 15 May 2020 13:48:12 +0200 (CEST) Received: from mail.madpilot.net ([192.168.254.3]) by mail (mail.madpilot.net [192.168.254.3]) (amavisd-new, port 10026) with ESMTP id Fuxcfmf7kiMM; Fri, 15 May 2020 13:48:09 +0200 (CEST) Subject: Re: [HEADSUP] Disallowing read() of a directory fd To: =?UTF-8?Q?Stefan_E=c3=9fer?= , Arne Steinkamm Cc: freebsd-arch@freebsd.org, FreeBSD Hackers References: <202005142017.04EKH0aA093503@fire.js.berklix.net> <20200514203030.GT82984@trajan.stk.cx> <20200515011258.GW82984@trajan.stk.cx> From: Guido Falsi Autocrypt: addr=mad@madpilot.net; keydata= mQENBE+G+l0BCADi/WBQ0aRJfnE7LBPsM0G3m/m3Yx7OPu4iYFvS84xawmRHtCNjWIntsxuX fptkmEo3Rsw816WUrek8dxoUAYdHd+EcpBcnnDzfDH5LW/TZ4gbrFezrHPdRp7wdxi23GN80 qPwHEwXuF0X4Wy5V0OO8B6VT/nA0ADYnBDhXS52HGIJ/GCUjgqJn+phDTdCFLvrSFdmgx4Wl c0W5Z1p5cmDF9l8L/hc959AeyNf7I9dXnjekGM9gVv7UDUYzCifR3U8T0fnfdMmS8NeI9NC+ wuREpRO4lKOkTnj9TtQJRiptlhcHQiAlG1cFqs7EQo57Tqq6cxD1FycZJLuC32bGbgalABEB AAG0Hkd1aWRvIEZhbHNpIDxtYWRAbWFkcGlsb3QubmV0PokBOQQTAQgAIwIbAwIeAQIXgAUL CQgHAwUVCgkICwQWAgMBBQJS79AgAhkBAAoJEBrmhg5Wy9KTc0kH/RO64ORBlTbTHaUaOj8F Je5O5NU2Pt9Cyt5ZWBRvxntr1zPTJGKRPS9ihlIfqT4ZvEngQGp57EUyFbCpI0UWasTerImM tt5WACnGmCzUTB39UXx8Oy4b1EgWeTJQ747e/F1mQLXTNa6ijRBE9fYlTb4gAkPN88/wVV9v 3PZozKLTg16ghBzHM/P7Lk8L7clPEZChX1FTa/6eSt3nvzfCuTMZbBPJF/ph+q1KyPqRgVfh tyhu5dvgMoPz/ni41IfeSrkJTD5RXzdyGR9q4Z1NYeBsLkRjC4LxKAP5KqUsvlOUjKvO1byj ApYdMarol+IGkaSk9e3zVYAJkWKjn/ni8Xa5Ag0EUxB7QQEQAKFhrDceoPdK/IHDSmoj6SQY isvM7VdhcleS7E9DoEAVt7yMbf6HbbMVTTY6ckvwTWQssywLBXNVqxgc4WLJjzfUhgef+WE7 5M3+WFYlOVQLGZY/zEVgma1raYnOHNAOzeHLDmEXjbZP6vGAeDyBbGfQPpE7qGYZ7ubeT3Xw QO+PklcCrvOPj2ZPcAxGNS2xVU/LzONqCrJqLMJSIcCdsbiSP4G5PnDFHtMokaTY6OEr8OEQ fOAerhcHUa/z7Uu8YtmaqKH+QGkE/WEgaRqSiTnv0JOTD+DxehaqvoKPPZ++2NpCZMHB2i6A /xifmQwEiIjEXtcueBRzkNUQkxhqZyS13SrhocL9ydtaVPBzZatAEjUDDEJmAMLVFs45qfyh MiNapHJo2n3MW/E5omqCvEkDdWX/en3P7CK2TemeaDghMsgkNKax/z0wNo5UZCkOPOz0xpNi UilOVbkuezZZNg65741qee2lfXhQIaZ66yT7hphc/N/z3PIAtLeze4u1VR2EXAuZ2sWAdlKC NTlJMsaU/x70BV11Wd/ypnVzM68dfdQIIAj1iMFAD/lXGlEUmKXg5Ov2VQDlTntQoanCYrAg +8CttPzjrydgLZFq3hrtQmfc0se5yv1WHS69+BsUOG09RvvawUDZxUjW19kyeN9THaNRgow3 kSuArUp6zSmJABEBAAGJAR8EGAEIAAkFAlMQe0ECGwwACgkQGuaGDlbL0pMN5wgA4bCkX/qw EVC06ToeR6C2putmSWQMgpDaqrv65Hubo+QGmg2P4ewTYQQ4g6oYWS03qHxqVVWhKz7FjfrV +dH8qbCLfSgIcvdBha7ayGZVrsiuMLKGbw36fcmkZPpSDOfHcP0XH8Z+u9CWj0xUkTxAlZ/7 i6gYSUpG2JWNtdmE/X8VVEyXusCLwy0K0BI60A/4dRTIX3C4QKrJ3ZbUXegz70ynjHf+lQMZ 9IZKASoRMuS5FozPQh6abvmwZEPdf5I9riUElzvHrqJ8Bx0t3Pujdoth+yNHpnBxrtO8LkQd rQ58P0SwcaIX33T2U9pG8bhu5YVR88FQ8OQ0cEsPBpDncrkBDQRPhvpdAQgAsd6mrOq1GSZw lzRscNQa9W2WB/3Tj4ON4PL2e9B+hc9lT/ny2zB3agXu5wbsXTzwxgJpQT7hNHkCSckW98h3 HRjFfhZPNCgInuUGsjcNyVguQh+/47ckhph0s7U+6B4yNuIiqQZk4mo8WgCNj1YIihVmGWEs gDOwMaajbDYZ0r1/3GkKlYjOXeUuT/WgourrSR5oZJVNA/k4X2H7M3JUr1BSc32L7BJt8M7A ntul6k17J0L8GmkvLvTUtQTO+p+DYQMna2ngD3PbAvQRcbEGnkg9ABrdEF0Wp4Gx+gGGWsyF KlHvPdMtgWAy3JsS+rQapG6LoW3yUJpwpEpA86KdBwARAQABiQEfBCgBCAAJBQJTEH0NAh0B AAoJEBrmhg5Wy9KTMZcIAMSsidGF4KpjGcKzhkNK0sEpevcelQ6DzgT7kcXuq6LQ6YOrbof2 /KPgGie9/ToFZfJXH8zE5GefqkKvHZbYssWilFvkI90F9n138kG205NB/2zlaQb74/v9ZMXJ XcipnIx+T2tOMCBgHJU41IMJmB+NfRt5A6CDytJdhWxqppsEo5jjy/7tJM1Nn47G87tAV8qV NUtzbS6zdnbHB4W2BJwCObbVv8epL3hu/L5efV2j2tSbVTmyvK/ClYMBqdtUo3uPX75GF/Ku YDCOP1BTA5zzmzp4PMVd+gmHcMgCZKY6lvcEtdi5FLI0we2kcY8ffPvM2d6MNhFsGLaVI95J 0oqJAR8EGAECAAkFAk+G+l0CGwwACgkQGuaGDlbL0pM18Qf9HTNNhu8N0ISKtmR8lgPhJuu8 9rOEa8KKEatr4fQ7gL+hmYOEqZ/yHLcPQvGxbAlLR7F0SheKvAEk4B1aFwGULPo0SzuO0d/W tVMEbGa95JTm/6mfiymWMlWf8UifD1MDKzzPR7Om0ybeoPM8S/RQTboUU1WLpwd4mg9pVJlK 0xr55GOSHNf4m7S+P1kvl3xgmEj14zVMq9yJBNWFlsQK5ciifh7sFpfuxWdEVbtgIdxpzImK LXSLA0vOroKAvxFTGBrBq3vxV6eUmaKyd5HbbWejmafY1ua5dcnew9lxpWKLdqkC27Vt0Cku +LtTY3325V+BChncwNcJJS7IMmBz6w== Message-ID: Date: Fri, 15 May 2020 13:48:05 +0200 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 49NmrM3ZYTz3DjC X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.15 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[madpilot.net:s=bjowvop61wgh]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+mx]; MISSING_MIME_VERSION(2.00)[]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(-2.15)[ip: (-8.67), ipnet: 159.69.0.0/16(-0.59), asn: 24940(-1.48), country: DE(-0.02)]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_DN_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[madpilot.net:+]; DMARC_POLICY_ALLOW(-0.50)[madpilot.net,quarantine]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:24940, ipnet:159.69.0.0/16, country:DE]; MID_RHS_MATCH_FROM(0.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 11:48:21 -0000 On 15/05/20 11:47, Stefan Eßer wrote: > Am 15.05.20 um 03:12 schrieb Arne Steinkamm: >> On Thu, May 14, 2020 at 02:20:45PM -0600, Alan Somers wrote: >>> On Thu, May 14, 2020 at 2:17 PM Julian H. Stacey wrote: >>> >>>> Kyle Evans wrote: >>>>> Hi, >>>>> >>>>> This is a heads up, given that I'm completely flipping our historical >>>>> behavior- I intend to commit this review in a couple days' time >>>>> without substantial objection: https://reviews.freebsd.org/D24596 >>>>> >>>>> With this, FreeBSD 13 will not allow read() of a directory fd, which >>>>> could have previously returned some data from the underlying >>>>> filesystem in no particular standardized format. >>>>> >>>>> This is a still-standards-compliant switch from one >>>>> implementation-defined behavior to another that's already been adopted >>>>> in various other popular kernels, to include OpenBSD, MacOS, and >>>>> Linux. >>>>> >>>>> Worth noting is that there's not really one largely-compelling reasons >>>>> to switch this after so many years (unless you find yourself that >>>>> irate when you accidentally `cat` a directory), but there are some >>>>> benefits which are briefly discussed in the commentary around the >>>>> review along with the history of the current behavior. >>>>> >>>>> This change also simplifies filesystem implementations to some extent. >>>>> >>>>> Thanks, >>>>> >>>>> Kyle Evans >>>> >>>> There is ZERO need for a spurious change at 2 days notice after 42+ years ! >>>> >>>> "cat ." as been supported since Unix V6 1978 or earlier, >>>> no problem, even occasionaly useful. >>>> >>> >>> Really? When is that occasionally useful? I've never seen anything useful >>> come out of reading a directory. >> >> It's all about files in Unix... >> >> This is true since 1972. >> >> And files can be read! >> >> How many (bad programmed) shell scripts will break when directory files can't >> be read anymore? I have no idea. > > And how many shell scripts will break if you migrate from UFS to ZFS > which does not return the same data? > > Reading a directory entry as a byte stream for low level debugging has > been the only valid use case I've seen in this thread. > > And I'm convinced that any developer going to work on that part of UFS > would consider adding debug code to provide or display that information > (or remove the error return just for local testing) a minor annoyance. > >> But I know for sure that there is no need to make this change. >> Not 1976, not 2020 nor in the future. > > There might be no need in the strict sense, but some reasons have been > provided: > > - Linux, macOS, OpenBSD do it (not a good reason in itself) > > - applications developed with Linux or macOS in mind might expect it > (and that is a valid reason, IMHO) Chiming in just to note that this is not a theoretical thing, I stumbled upon such a problem of this a little time ago: https://github.com/yarnpkg/yarn/issues/4884 -- Guido Falsi From owner-freebsd-hackers@freebsd.org Fri May 15 12:47:47 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 626D12F4B22; Fri, 15 May 2020 12:47:47 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49Np8y51MYz3JBC; Fri, 15 May 2020 12:47:46 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 04FClh3b086498; Fri, 15 May 2020 05:47:43 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 04FClhsD086497; Fri, 15 May 2020 05:47:43 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <202005151247.04FClhsD086497@gndrsh.dnsmgr.net> Subject: Re: [HEADSUP] Disallowing read() of a directory fd In-Reply-To: To: =?UTF-8?Q?Stefan_E=C3=9Fer?= Date: Fri, 15 May 2020 05:47:43 -0700 (PDT) CC: Arne Steinkamm , freebsd-arch@freebsd.org, FreeBSD Hackers X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 49Np8y51MYz3JBC X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-5.97 / 15.00]; NEURAL_HAM_MEDIUM(-0.97)[-0.967,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 12:47:48 -0000 > Am 15.05.20 um 03:12 schrieb Arne Steinkamm: > > On Thu, May 14, 2020 at 02:20:45PM -0600, Alan Somers wrote: > >> On Thu, May 14, 2020 at 2:17 PM Julian H. Stacey wrote: > >> > >>> Kyle Evans wrote: > >>>> Hi, > >>>> > >>>> This is a heads up, given that I'm completely flipping our historical > >>>> behavior- I intend to commit this review in a couple days' time > >>>> without substantial objection: https://reviews.freebsd.org/D24596 > >>>> > >>>> With this, FreeBSD 13 will not allow read() of a directory fd, which > >>>> could have previously returned some data from the underlying > >>>> filesystem in no particular standardized format. > >>>> > >>>> This is a still-standards-compliant switch from one > >>>> implementation-defined behavior to another that's already been adopted > >>>> in various other popular kernels, to include OpenBSD, MacOS, and > >>>> Linux. > >>>> > >>>> Worth noting is that there's not really one largely-compelling reasons > >>>> to switch this after so many years (unless you find yourself that > >>>> irate when you accidentally `cat` a directory), but there are some > >>>> benefits which are briefly discussed in the commentary around the > >>>> review along with the history of the current behavior. > >>>> > >>>> This change also simplifies filesystem implementations to some extent. > >>>> > >>>> Thanks, > >>>> > >>>> Kyle Evans > >>> > >>> There is ZERO need for a spurious change at 2 days notice after 42+ years ! > >>> > >>> "cat ." as been supported since Unix V6 1978 or earlier, > >>> no problem, even occasionaly useful. > >>> > >> > >> Really? When is that occasionally useful? I've never seen anything useful > >> come out of reading a directory. > > > > It's all about files in Unix... > > > > This is true since 1972. > > > > And files can be read! > > > > How many (bad programmed) shell scripts will break when directory files can't > > be read anymore? I have no idea. > > And how many shell scripts will break if you migrate from UFS to ZFS > which does not return the same data? I believe there is some confusion over what the symantics of read means on a directory and what is being changed, and file protections. This change does not change the actual protection on a directory, so the effect on if [ -r ${pathname} ]; is none. > > Reading a directory entry as a byte stream for low level debugging has > been the only valid use case I've seen in this thread. > > And I'm convinced that any developer going to work on that part of UFS > would consider adding debug code to provide or display that information > (or remove the error return just for local testing) a minor annoyance. The use case is usually an emergency and these options are generally not very viable solutions. > > > But I know for sure that there is no need to make this change. > > Not 1976, not 2020 nor in the future. > > There might be no need in the strict sense, but some reasons have been > provided: > > - Linux, macOS, OpenBSD do it (not a good reason in itself) > > - applications developed with Linux or macOS in mind might expect it > (and that is a valid reason, IMHO) Thats actually a bad reason, as this only allows non portable code to remain non portable without consequence. > > - currently we make no guarantee with regard to success or failure of > reading a directory - it depends on the choice made by the file system > (and technical limitations, e.g. in case of NFS) > > - information could be leaked that is of use to an attacker (and that > might have been the main reason it has been prohibited in OpenBSD) > > Every script run by an unprivileged user ought to be able to deal with a > directory that cannot be read e.g. because of insufficient privilege. > > A script run by root should never depend on unspecified behavior (even > if in case that it has been defined behavior in BSD for a long time). > > I'm convinced that there is more code today that has been developed on > Linux and breaks on FreeBSD, unless specifically patched, then there are > shell scripts that break when directory access is limited to the access > functions provided for this purpose for decades. > > I've always been a strong supporter of POLA, but do not see how this > suggested change is going to be a violation of that principle. > > > We could make this change in -CURRENT, not MFC at all or after a long > period of testing whether there is any fall-out, and then decide whether > we want it backed out or controller by a tunable or sysctl. > > Such an experiment in -CURRENT (announced on the appropriate lists) > should not cause any trouble or churn for developers and let us find > out, if there really is some negative impact. I can support this change so long as there is a *RUN* time way to disable it for root which does not require a reboot of any kind. Much like Kirk, and Poul who have pointed out a use cases when doing a UFS data recovery this is a usefull feature. Often the directory tree is valid, but the file names are mangled. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-hackers@freebsd.org Fri May 15 13:14:53 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 070722F5485 for ; Fri, 15 May 2020 13:14:53 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 49NpmD6MPGz3KZN for ; Fri, 15 May 2020 13:14:52 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id D87402F5481; Fri, 15 May 2020 13:14:52 +0000 (UTC) Delivered-To: hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D81962F5480; Fri, 15 May 2020 13:14:52 +0000 (UTC) (envelope-from kevans@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) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49NpmD5RdXz3KZL; Fri, 15 May 2020 13:14:52 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-qt1-f169.google.com (mail-qt1-f169.google.com [209.85.160.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id ACD331A7DC; Fri, 15 May 2020 13:14:52 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qt1-f169.google.com with SMTP id v4so1874383qte.3; Fri, 15 May 2020 06:14:52 -0700 (PDT) X-Gm-Message-State: AOAM531OB48/vUcUNo2SmbhZ4uPiuWbkyCaMJc/3fzpAzvOLQxaW4RXY PU3dIHHk6MjLsIx4s6Ydt6j0AtlDnzphGbWs4RA= X-Google-Smtp-Source: ABdhPJxIaPHlcjrzuRWHQGtahZPlCxiqJV30sYCkl/zlY3HM2OwIuz0tWonr8K+g7cmepdHrf3OPdhRH/z5Rz+Z/qQM= X-Received: by 2002:ac8:2fb9:: with SMTP id l54mr1797432qta.211.1589548492143; Fri, 15 May 2020 06:14:52 -0700 (PDT) MIME-Version: 1.0 References: <202005142017.04EKH0aA093503@fire.js.berklix.net> <33549.1589488226@critter.freebsd.dk> <35501.1589529102@critter.freebsd.dk> In-Reply-To: <35501.1589529102@critter.freebsd.dk> From: Kyle Evans Date: Fri, 15 May 2020 08:14:38 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [HEADSUP] Disallowing read() of a directory fd To: Poul-Henning Kamp Cc: Alan Somers , "Julian H. Stacey" , "freebsd-arch@freebsd.org" , "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 13:14:53 -0000 On Fri, May 15, 2020 at 2:51 AM Poul-Henning Kamp wrote: > > -------- > In message > , Kyle Evans writes: > >On Thu, May 14, 2020 at 3:30 PM Poul-Henning Kamp wrote: > > >Can we explore the possibility of using fsdb(8) to fulfill these needs > >in a way that you'd be comfortable with? >> > Summary: I'm perfectly fine with read(2) returning error on a > directory *under normal circumstances*, and I think it makes good > sense by protecting a lot of terminals from a lot of binary > garbage. > > But there is absolutely no reason to make it *impossible* for > a competent root to do what competent roots do. > First, apologies if my previous message had offended you -- I didn't mean for this, but as you can tell I was not well-equipped to discuss the possibilities with a seasoned veteran such as yourself. I've prepared a patch locally to update the review that both hides it off behind security.bsd.allow_read_dir (default off) and restricts it to a new PRIV_VFS_READ_DIR that *is not* granted to jailed root. I know we've already discussed this to some extent, but can you confirm that these restrictions are reasonable and acceptable for you? I've tentatively placed it in the security.bsd.* namespace because it can and has had security implications, but I'm certainly not dead-set on it staying there. Thanks, Kyle Evans From owner-freebsd-hackers@freebsd.org Fri May 15 14:48:30 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id DBA932F74B2; Fri, 15 May 2020 14:48:30 +0000 (UTC) (envelope-from db@db.net) Received: from tfm.com (mtbaker.tfm.com [192.231.224.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.tfm.com", Issuer "Sectigo RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49NrrF1fcJz3RDP; Fri, 15 May 2020 14:48:28 +0000 (UTC) (envelope-from db@db.net) Received: from night.db.net (DB-DSL.ServerNorth.com [98.124.61.131]) (authenticated bits=0) by tfm.com (8.14.4/8.14.4) with ESMTP id 04FEmHt5000390 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 May 2020 07:48:19 -0700 (PDT) Date: Fri, 15 May 2020 10:48:15 -0400 From: Diane Bruce To: "Rodney W. Grimes" Cc: Stefan =?iso-8859-1?Q?E=DFer?= , Arne Steinkamm , freebsd-arch@freebsd.org, FreeBSD Hackers Subject: Re: [HEADSUP] Disallowing read() of a directory fd Message-ID: <20200515144815.GA8265@night.db.net> References: <202005151247.04FClhsD086497@gndrsh.dnsmgr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <202005151247.04FClhsD086497@gndrsh.dnsmgr.net> X-Rspamd-Queue-Id: 49NrrF1fcJz3RDP X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of db@db.net has no SPF policy when checking 192.231.224.2) smtp.mailfrom=db@db.net X-Spamd-Result: default: False [-1.53 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.94)[-0.943,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-0.88)[-0.879,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[db.net]; AUTH_NA(1.00)[]; RCPT_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:10488, ipnet:192.231.224.0/22, country:US]; RCVD_COUNT_TWO(0.00)[2]; IP_SCORE(-0.61)[ip: (-1.59), ipnet: 192.231.224.0/22(-0.79), asn: 10488(-0.63), country: US(-0.05)] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 14:48:30 -0000 On Fri, May 15, 2020 at 05:47:43AM -0700, Rodney W. Grimes wrote: > > Am 15.05.20 um 03:12 schrieb Arne Steinkamm: ... > > >>>> Worth noting is that there's not really one largely-compelling reasons > > >>>> to switch this after so many years (unless you find yourself that > > >>>> irate when you accidentally `cat` a directory), but there are some > > >>>> benefits which are briefly discussed in the commentary around the > > >>>> review along with the history of the current behavior. All I have to say on this noisy bikeshed is, let's resurrect the mkdir bug of V7 because it's tradition and the BSD way and history and stuff. (I only expect a few of you to remember this one.) Diane -- - db@FreeBSD.org db@db.net http://www.db.net/~db From owner-freebsd-hackers@freebsd.org Fri May 15 15:04:32 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 8AEE12F7AA6 for ; Fri, 15 May 2020 15:04:32 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 49NsBl6d8Nz3xVg for ; Fri, 15 May 2020 15:04:31 +0000 (UTC) (envelope-from jhs@berklix.com) Received: by mailman.nyi.freebsd.org (Postfix) id E16202F7AA3; Fri, 15 May 2020 15:04:31 +0000 (UTC) Delivered-To: hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id DEF242F7AA2; Fri, 15 May 2020 15:04:31 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from slim.berklix.org (slim.berklix.org [94.185.90.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "slim.berklix.org", Issuer "slim.berklix.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 49NsBj1nRvz3xVf; Fri, 15 May 2020 15:04:28 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from mart.js.berklix.net (p5DDB7209.dip0.t-ipconnect.de [93.219.114.9]) (authenticated bits=128) by slim.berklix.org (8.15.2/8.15.2) with ESMTPSA id 04FF4NXr065035 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 May 2020 17:04:27 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id 04FF4MZC098672; Fri, 15 May 2020 17:04:22 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.7/8.14.7) with ESMTP id 04FF423p040952; Fri, 15 May 2020 17:04:12 +0200 (CEST) (envelope-from jhs@berklix.com) Message-Id: <202005151504.04FF423p040952@fire.js.berklix.net> To: "freebsd-arch@freebsd.org" , "freebsd-hackers@freebsd.org" Cc: Kyle Evans , Poul-Henning Kamp , Alan Somers , Arne Steinkamm Subject: Re: [HEADSUP] Disallowing read() of a directory fd From: "Julian H. Stacey" Organization: http://berklix.com/jhs http://stolenvotes.uk User-agent: EXMH on FreeBSD http://berklix.com/free/ X-From: http://www.berklix.org/~jhs/ In-reply-to: Your message "Fri, 15 May 2020 08:14:38 -0500." Date: Fri, 15 May 2020 17:04:02 +0200 X-Rspamd-Queue-Id: 49NsBj1nRvz3xVf X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of jhs@berklix.com has no SPF policy when checking 94.185.90.68) smtp.mailfrom=jhs@berklix.com X-Spamd-Result: default: False [0.44 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.73)[-0.727,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[berklix.com]; AUTH_NA(1.00)[]; RCPT_COUNT_FIVE(0.00)[6]; HAS_ORG_HEADER(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.27)[0.273,0]; RCVD_IN_DNSWL_NONE(0.00)[68.90.185.94.list.dnswl.org : 127.0.10.0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:33824, ipnet:94.185.88.0/22, country:DE]; RCVD_TLS_LAST(0.00)[]; IP_SCORE(-0.00)[ip: (0.01), ipnet: 94.185.88.0/22(0.01), asn: 33824(-0.00), country: DE(-0.02)]; RECEIVED_SPAMHAUS_PBL(0.00)[9.114.219.93.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 15:04:32 -0000 Kyle Evans wrote: > On Fri, May 15, 2020 at 2:51 AM Poul-Henning Kamp wrote: > > > > -------- > > In message > > , Kyle Evans writes: > > >On Thu, May 14, 2020 at 3:30 PM Poul-Henning Kamp wrote: > > > > >Can we explore the possibility of using fsdb(8) to fulfill these needs > > >in a way that you'd be comfortable with? > >> > > Summary: I'm perfectly fine with read(2) returning error on a > > directory *under normal circumstances*, and I think it makes good > > sense by protecting a lot of terminals from a lot of binary > > garbage. > > > > But there is absolutely no reason to make it *impossible* for > > a competent root to do what competent roots do. > > > > First, apologies if my previous message had offended you -- I didn't > mean for this, but as you can tell I was not well-equipped to discuss > the possibilities with a seasoned veteran such as yourself. > > I've prepared a patch locally to update the review that both hides it > off behind security.bsd.allow_read_dir (default off) and restricts it > to a new PRIV_VFS_READ_DIR that *is not* granted to jailed root. I No. Root is Root regardless if in a jail or not. A root admin of a server in a jail needs full power without waiting days to contact other root human who owns the prison, without wasting human time of jail owner & prison owner formulating email request & considering & enabling requirement. kevans@ wasted FreeBSD time with threat of change at 2 days notice, for an issue unchanged since 1972. The rush was immature. kevans@ should retract his threat of forced urgent change, or expect core@ be asked to remove his commit bit while FreeBSD considers _un-rushed_, allowing sufficient time for all to consider options, & to warn users in RELNOTES of any potential future change. > know we've already discussed this to some extent, but can you confirm > that these restrictions are reasonable and acceptable for you? I've > tentatively placed it in the security.bsd.* namespace because it can > and has had security implications, but I'm certainly not dead-set on > it staying there. > > Thanks, > > Kyle Evans > Cheers -- Julian Stacey, Consultant Systems Engineer, BSD Linux http://berklix.com/jhs/ http://www.berklix.org/corona/#masks Tie 2 handkerchiefs or 1 pillow case. Jobs & economy hit by Corona to be hit again by Crash Brexit 31st Dec. 2020 From owner-freebsd-hackers@freebsd.org Fri May 15 15:06:55 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 126252F7C96; Fri, 15 May 2020 15:06:55 +0000 (UTC) (envelope-from arne@Steinkamm.COM) Received: from mail.steinkamm.com (mail.steinkamm.com [194.127.175.194]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "steinkamm.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49NsFS5Ws5z3xr0; Fri, 15 May 2020 15:06:52 +0000 (UTC) (envelope-from arne@Steinkamm.COM) Received: from trajan.stk.cx (trajan.stk.cx [10.8.8.110]) by basis.steinkamm.com (8.15.2/8.15.2) with ESMTPS id 04FF6dt3014096 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 15 May 2020 17:06:39 +0200 (CEST) (envelope-from arne@steinkamm.com) Received: from trajan.stk.cx (localhost [127.0.0.1]) by trajan.stk.cx (8.15.2/8.15.2) with ESMTPS id 04FF6cxw065070 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 15 May 2020 17:06:38 +0200 (CEST) (envelope-from arne@trajan.stk.cx) Received: (from arne@localhost) by trajan.stk.cx (8.15.2/8.15.2/Submit) id 04FF6RIZ064487; Fri, 15 May 2020 17:06:27 +0200 (CEST) (envelope-from arne) Date: Fri, 15 May 2020 17:06:27 +0200 From: Arne Steinkamm To: Diane Bruce Cc: "Rodney W. Grimes" , Arne Steinkamm , FreeBSD Hackers , freebsd-arch@freebsd.org Subject: Re: [HEADSUP] Disallowing read() of a directory fd Message-ID: <20200515150627.GY82984@trajan.stk.cx> Reply-To: arne@Steinkamm.COM References: <202005151247.04FClhsD086497@gndrsh.dnsmgr.net> <20200515144815.GA8265@night.db.net> MIME-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200515144815.GA8265@night.db.net> User-Agent: Mutt@Trajan/1.12.1 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on basis.steinkamm.com X-Rspamd-Queue-Id: 49NsFS5Ws5z3xr0 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of arne@Steinkamm.COM has no SPF policy when checking 194.127.175.194) smtp.mailfrom=arne@Steinkamm.COM X-Spamd-Result: default: False [0.82 / 15.00]; ARC_NA(0.00)[]; HAS_REPLYTO(0.00)[arne@Steinkamm.COM]; NEURAL_HAM_MEDIUM(-0.47)[-0.470,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; IP_SCORE(-0.00)[country: DE(-0.02)]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[Steinkamm.COM]; REPLYTO_DOM_EQ_FROM_DOM(0.00)[]; AUTH_NA(1.00)[]; RCPT_COUNT_FIVE(0.00)[5]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.10)[0.098,0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[freebsd-hackers@Steinkamm.COM,arne@Steinkamm.COM]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:34646, ipnet:194.127.175.0/24, country:DE]; FROM_NEQ_ENVFROM(0.00)[freebsd-hackers@Steinkamm.COM,arne@Steinkamm.COM]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 15:06:55 -0000 On Fri, May 15, 2020 at 10:48:15AM -0400, Diane Bruce wrote: > All I have to say on this noisy bikeshed is, let's resurrect the mkdir > bug of V7 because it's tradition and the BSD way and history and stuff. > (I only expect a few of you to remember this one.) Oh, this "bug" was alive until Sys V 3.2 times... Implementing mkdir as library function without a syscall wasn't a good idea. ken and dmr saw no reason to implement mkdir as atomic operation. So it was easy, even with a shell script, to jump between the mknod(2) and the chown(2) to replace the directory node with a symlink to /etc/passwd. This was from a todays point of view a stupid mistake. Reading a directory node is lightyears away from "a stupid mistake". Make it switchable with a sysctl switch... would be the best of both worlds. .//. Arne -- Arne Steinkamm | Home: Mail: arnesteinkammcom Tel.: +49.89.21031004 | Gröbenbachweg 13, 82178 Puchheim, GERMANY From owner-freebsd-hackers@freebsd.org Fri May 15 15:57:26 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id F0C922F8F68 for ; Fri, 15 May 2020 15:57:26 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 49NtMp4f9fz42Qx for ; Fri, 15 May 2020 15:57:26 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.nyi.freebsd.org (Postfix) id 9F6212F8F65; Fri, 15 May 2020 15:57:26 +0000 (UTC) Delivered-To: hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 9F2632F8F64 for ; Fri, 15 May 2020 15:57:26 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) 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 49NtMm6ndBz42Qw for ; Fri, 15 May 2020 15:57:24 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x729.google.com with SMTP id s1so3004861qkf.9 for ; Fri, 15 May 2020 08:57:24 -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=HFVsw8xrDbCjCjBYoo05RlgaBUbn9FgcTIAV2OIKs54=; b=JoPiXNFZKp9gLa8oZvkHl8UAxZwdWBugiJn7GhRkpF9impORES8zSmj/PkRccCRqcq SZ9ZxxtAJ3Qll8Bayt+U7Z4kKV5gEuCSCbrHZwefebsisaOL8C7jBDJR2aIYhitvUksM 8y9U1hMc5YzHUQsplNI6SRxPT8fql3u9qI8maegpOojj332JmLuVC4TktsTXR9pgLHwy 4S1rI0ZDYWZ60D5YGVt35TtMpXGXyu+cKwTJqOO2y3U5Q2ioFEm/Yy2EaG0FlfFm/o6p gtGhFUVEcByUWJqhKdsFnChvi/kL9OxIp+GDsu9lY7FEZWcef95hUlYGZm0Y9N4ne0s3 5cVA== 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=HFVsw8xrDbCjCjBYoo05RlgaBUbn9FgcTIAV2OIKs54=; b=FaaGujjPpUQFixcCHmjbvd0wE2o5qDAXQON02IE66rnm63N+Hp2Nc/1rQH8O6CZtNb nVyFGF8NcTYwhwdQXkevqVsof+QvgqOKVEhO14fJ8J1QiotuKWdZbYoJrFJKTKeW3qBe Ym/VI4aSMOz6HI5qd08Z5nVrXo0M0ySzENCZ9k5anYXZzDecCAiw92sTHzD9/BKxV2GH PF/AFnEwb5FNuTmIJ01GykCVfuCOaygxbfKwJ3UESy27OatL6nahHChA8ZSefW6Cg0wA vFnLoA3eWQMXAcuTQgEJXJv9Xnm5jWgRZg6WJ4gttJAaXP6IrEXTycwkzMMuPUh9N6+t 6iRg== X-Gm-Message-State: AOAM532HoCdRqw1fRGOOLxQYZEIVSGMthqL+Nhmi35wiSER+yQqxPzPH uM3Nn65n0RkU3gPJ5hOJtYP5RHy0Jo+r6ZrScQNzRQ== X-Google-Smtp-Source: ABdhPJzZfy7QIXi9UWVLT4yCy0VkHE/1gD4q0Bu/z3AE0bKs+3VejTmRM6fOFG0gAFv/Cf74IklClk/3fUMU1OKt45s= X-Received: by 2002:a05:620a:5bc:: with SMTP id q28mr4101296qkq.60.1589558243731; Fri, 15 May 2020 08:57:23 -0700 (PDT) MIME-Version: 1.0 References: <202005151504.04FF423p040952@fire.js.berklix.net> In-Reply-To: <202005151504.04FF423p040952@fire.js.berklix.net> From: Warner Losh Date: Fri, 15 May 2020 09:57:12 -0600 Message-ID: Subject: Re: [HEADSUP] Disallowing read() of a directory fd To: "Julian H. Stacey" Cc: "freebsd-arch@freebsd.org" , "freebsd-hackers@freebsd.org" , Kyle Evans , Poul-Henning Kamp , Alan Somers , Arne Steinkamm X-Rspamd-Queue-Id: 49NtMm6ndBz42Qw X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=JoPiXNFZ; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::729) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-3.96 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[hackers@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; RCVD_IN_DNSWL_NONE(0.00)[9.2.7.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; RCPT_COUNT_SEVEN(0.00)[7]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; IP_SCORE(-1.96)[ip: (-9.01), ipnet: 2607:f8b0::/32(-0.33), asn: 15169(-0.42), country: US(-0.05)]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 15:57:27 -0000 On Fri, May 15, 2020 at 9:04 AM Julian H. Stacey wrote: > kevans@ wasted FreeBSD time with threat of change at 2 days notice, > for an issue unchanged since 1972. The rush was immature. > > kevans@ should retract his threat of forced urgent change, or expect > core@ be asked to remove his commit bit while FreeBSD considers > _un-rushed_, allowing sufficient time for all to consider options, > & to warn users in RELNOTES of any potential future change. > Threats are not tolerated in this project. This hyperbolic response has gone on long enough. Please stop and treat your fellow committers with respect and a certain level of professionalism. He's done none of the nefarious things you've said (I've known about this changes for days if not weeks as he socialized it, for example). He doesn't deserve this level of grief over a proposal. It's a request for comments, not a request for abuse and nasty behaviour. This whole thread has gone toxic / hyperbolic over a non-issue. You should have stopped reading directories in 1983 when readdir was introduced because UFS broke ls, find, du, etc. At best, it's a nice debugging tool some folks don't want to lose. At worst, it causes bugs for programs that accidentally read directories (and maybe some, like grep, need some minor changes). It's not worth this much bile and venom. Warner From owner-freebsd-hackers@freebsd.org Fri May 15 16:00:59 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 9A5662F912D for ; Fri, 15 May 2020 16:00:59 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 49NtRv3C6Cz42hZ for ; Fri, 15 May 2020 16:00:59 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: by mailman.nyi.freebsd.org (Postfix) id 6BDBF2F912B; Fri, 15 May 2020 16:00:59 +0000 (UTC) Delivered-To: hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 6B8222F912A; Fri, 15 May 2020 16:00:59 +0000 (UTC) (envelope-from jhb@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) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49NtRv0WvHz42hY; Fri, 15 May 2020 16:00:59 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-164.local (unknown [IPv6:2601:648:8203:2990:74f6:48c0:2e0b:8148]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 584441C0E4; Fri, 15 May 2020 16:00:58 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Subject: Re: [HEADSUP] Disallowing read() of a directory fd To: "Julian H. Stacey" , "freebsd-arch@freebsd.org" , "freebsd-hackers@freebsd.org" Cc: Kyle Evans , Poul-Henning Kamp , Alan Somers , Arne Steinkamm References: <202005151504.04FF423p040952@fire.js.berklix.net> From: John Baldwin Autocrypt: addr=jhb@FreeBSD.org; keydata= mQGiBETQ+XcRBADMFybiq69u+fJRy/0wzqTNS8jFfWaBTs5/OfcV7wWezVmf9sgwn8TW0Dk0 c9MBl0pz+H01dA2ZSGZ5fXlmFIsee1WEzqeJzpiwd/pejPgSzXB9ijbLHZ2/E0jhGBcVy5Yo /Tw5+U/+laeYKu2xb0XPvM0zMNls1ah5OnP9a6Ql6wCgupaoMySb7DXm2LHD1Z9jTsHcAQMD /1jzh2BoHriy/Q2s4KzzjVp/mQO5DSm2z14BvbQRcXU48oAosHA1u3Wrov6LfPY+0U1tG47X 1BGfnQH+rNAaH0livoSBQ0IPI/8WfIW7ub4qV6HYwWKVqkDkqwcpmGNDbz3gfaDht6nsie5Z pcuCcul4M9CW7Md6zzyvktjnbz61BADGDCopfZC4of0Z3Ka0u8Wik6UJOuqShBt1WcFS8ya1 oB4rc4tXfSHyMF63aPUBMxHR5DXeH+EO2edoSwViDMqWk1jTnYza51rbGY+pebLQOVOxAY7k do5Ordl3wklBPMVEPWoZ61SdbcjhHVwaC5zfiskcxj5wwXd2E9qYlBqRg7QeSm9obiBCYWxk d2luIDxqaGJARnJlZUJTRC5vcmc+iGAEExECACAFAkTQ+awCGwMGCwkIBwMCBBUCCAMEFgID AQIeAQIXgAAKCRBy3lIGd+N/BI6RAJ9S97fvbME+3hxzE3JUyUZ6vTewDACdE1stFuSfqMvM jomvZdYxIYyTUpC5Ag0ERND5ghAIAPwsO0B7BL+bz8sLlLoQktGxXwXQfS5cInvL17Dsgnr3 1AKa94j9EnXQyPEj7u0d+LmEe6CGEGDh1OcGFTMVrof2ZzkSy4+FkZwMKJpTiqeaShMh+Goj XlwIMDxyADYvBIg3eN5YdFKaPQpfgSqhT+7El7w+wSZZD8pPQuLAnie5iz9C8iKy4/cMSOrH YUK/tO+Nhw8Jjlw94Ik0T80iEhI2t+XBVjwdfjbq3HrJ0ehqdBwukyeJRYKmbn298KOFQVHO EVbHA4rF/37jzaMadK43FgJ0SAhPPF5l4l89z5oPu0b/+5e2inA3b8J3iGZxywjM+Csq1tqz hltEc7Q+E08AAwUIAL+15XH8bPbjNJdVyg2CMl10JNW2wWg2Q6qdljeaRqeR6zFus7EZTwtX sNzs5bP8y51PSUDJbeiy2RNCNKWFMndM22TZnk3GNG45nQd4OwYK0RZVrikalmJY5Q6m7Z16 4yrZgIXFdKj2t8F+x613/SJW1lIr9/bDp4U9tw0V1g3l2dFtD3p3ZrQ3hpoDtoK70ioIAjjH aIXIAcm3FGZFXy503DOA0KaTWwvOVdYCFLm3zWuSOmrX/GsEc7ovasOWwjPn878qVjbUKWwx Q4QkF4OhUV9zPtf9tDSAZ3x7QSwoKbCoRCZ/xbyTUPyQ1VvNy/mYrBcYlzHodsaqUDjHuW+I SQQYEQIACQUCRND5ggIbDAAKCRBy3lIGd+N/BCO8AJ9j1dWVQWxw/YdTbEyrRKOY8YZNwwCf afMAg8QvmOWnHx3wl8WslCaXaE8= Message-ID: Date: Fri, 15 May 2020 09:00:56 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <202005151504.04FF423p040952@fire.js.berklix.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 16:00:59 -0000 On 5/15/20 8:04 AM, Julian H. Stacey wrote: > Kyle Evans wrote: >> On Fri, May 15, 2020 at 2:51 AM Poul-Henning Kamp wrote: >>> >>> -------- >>> In message >>> , Kyle Evans writes: >>>> On Thu, May 14, 2020 at 3:30 PM Poul-Henning Kamp wrote: >>> >>>> Can we explore the possibility of using fsdb(8) to fulfill these needs >>>> in a way that you'd be comfortable with? >>>> >>> Summary: I'm perfectly fine with read(2) returning error on a >>> directory *under normal circumstances*, and I think it makes good >>> sense by protecting a lot of terminals from a lot of binary >>> garbage. >>> >>> But there is absolutely no reason to make it *impossible* for >>> a competent root to do what competent roots do. >>> >> >> First, apologies if my previous message had offended you -- I didn't >> mean for this, but as you can tell I was not well-equipped to discuss >> the possibilities with a seasoned veteran such as yourself. >> >> I've prepared a patch locally to update the review that both hides it >> off behind security.bsd.allow_read_dir (default off) and restricts it >> to a new PRIV_VFS_READ_DIR that *is not* granted to jailed root. I > > No. Root is Root regardless if in a jail or not. Nope. Even a cursory read of prison_priv_check in kern_jail.c makes this abundantly clear. > kevans@ should retract his threat of forced urgent change, or expect > core@ be asked to remove his commit bit while FreeBSD considers > _un-rushed_, allowing sufficient time for all to consider options, > & to warn users in RELNOTES of any potential future change. You are free to ask core@ whatever you want, but you don't have the authority or credibility to claim that core@ will follow your wishes. I've watched many threads involving you over the past several years, and the pattern of behavior I've observed is that you are inflexible and usually just flame anyone who disagrees with your view or opinion. That may have been normal practice 20 years ago on the mailing lists when I first joined the project, but it isn't the normal practice now. The effect right now is that most other developers who mention you at all only do so to note that they ignore you due to your behavior. If you wish to have a voice that others will listen to in the future, you need to change your behavior. -- John Baldwin From owner-freebsd-hackers@freebsd.org Fri May 15 16:11:30 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 8C0502F956D for ; Fri, 15 May 2020 16:11:30 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 49Nth21LrVz43j7 for ; Fri, 15 May 2020 16:11:30 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: by mailman.nyi.freebsd.org (Postfix) id 2C66F2F956B; Fri, 15 May 2020 16:11:30 +0000 (UTC) Delivered-To: hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 2C1C02F956A; Fri, 15 May 2020 16:11:30 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49Nth03KL7z43j4; Fri, 15 May 2020 16:11:27 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (v-critter.freebsd.dk [192.168.55.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by phk.freebsd.dk (Postfix) with ESMTPS id A2F331AF18C; Fri, 15 May 2020 16:11:25 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.15.2/8.15.2) with ESMTPS id 04FGBPOZ044548 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 15 May 2020 16:11:25 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.15.2/8.15.2/Submit) id 04FGBOt2044547; Fri, 15 May 2020 16:11:24 GMT (envelope-from phk) To: "Julian H. Stacey" cc: "freebsd-arch@freebsd.org" , "freebsd-hackers@freebsd.org" , Kyle Evans , Alan Somers , Arne Steinkamm Subject: Re: [HEADSUP] Disallowing read() of a directory fd In-reply-to: <202005151504.04FF423p040952@fire.js.berklix.net> From: "Poul-Henning Kamp" References: <202005151504.04FF423p040952@fire.js.berklix.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <44545.1589559084.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Fri, 15 May 2020 16:11:24 +0000 Message-ID: <44546.1589559084@critter.freebsd.dk> X-Rspamd-Queue-Id: 49Nth03KL7z43j4 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of phk@critter.freebsd.dk designates 130.225.244.222 as permitted sender) smtp.mailfrom=phk@critter.freebsd.dk X-Spamd-Result: default: False [-1.70 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.78)[-0.776,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-0.97)[-0.971,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.dk]; RCPT_COUNT_FIVE(0.00)[6]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; IP_SCORE(0.04)[ip: (0.06), ipnet: 130.225.0.0/16(0.08), asn: 1835(0.08), country: EU(-0.01)]; FORGED_SENDER(0.30)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU]; FROM_NEQ_ENVFROM(0.00)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 16:11:30 -0000 -------- In message <202005151504.04FF423p040952@fire.js.berklix.net>, "Julian H. S= tacey " writes: >No. Root is Root regardless if in a jail or not. No. See also: https://papers.freebsd.org/2000/phk-jails/ = -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= . From owner-freebsd-hackers@freebsd.org Fri May 15 16:23:05 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id BB64C2F9ACC for ; Fri, 15 May 2020 16:23:05 +0000 (UTC) (envelope-from freebsd@sysctl.cz) Received: from wes1-so1.wedos.net (wes1-so1.wedos.net [46.28.106.43]) (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 49NtxN38RRz44W6 for ; Fri, 15 May 2020 16:23:03 +0000 (UTC) (envelope-from freebsd@sysctl.cz) Received: from webmail.wedos.net (wes1-wm3.wedos.net [46.28.106.84]) by wes1-so1.wedos.net (Postfix) with ESMTPSA id 49NtxB62ZQz3Fv; Fri, 15 May 2020 18:22:54 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 15 May 2020 18:22:54 +0200 From: freebsd@sysctl.cz To: Konstantin Belousov Cc: Freebsd hackers Subject: Re: Debug linux binary with enable linux emulation In-Reply-To: <20200512174935.GK68906@kib.kiev.ua> References: <24f30eaa0597d79ddadc10d6f993f2a0@sysctl.cz> <20200511115656.GF68906@kib.kiev.ua> <67eed7f18b68f67ff04f628c4c367535@sysctl.cz> <20200512174935.GK68906@kib.kiev.ua> Message-ID: <0fd224d0e4bc643ec8980f2cd71d87c2@sysctl.cz> X-Sender: freebsd@sysctl.cz User-Agent: Roundcube Webmail/1.2.4 X-Rspamd-Queue-Id: 49NtxN38RRz44W6 X-Spamd-Bar: +++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd@sysctl.cz has no SPF policy when checking 46.28.106.43) smtp.mailfrom=freebsd@sysctl.cz X-Spamd-Result: default: False [3.87 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; IP_SCORE(1.05)[ipnet: 46.28.104.0/21(1.42), asn: 197019(3.76), country: CZ(0.09)]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[sysctl.cz]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.92)[0.920,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FROM_NO_DN(0.00)[]; NEURAL_SPAM_LONG(1.00)[0.999,0]; R_SPF_NA(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:197019, ipnet:46.28.104.0/21, country:CZ]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 16:23:05 -0000 Dne 2020-05-12 19:49, Konstantin Belousov napsal: > On Tue, May 12, 2020 at 12:49:25AM +0200, freebsd@sysctl.cz wrote: >> Dne 2020-05-11 13:56, Konstantin Belousov napsal: >> > On Mon, May 11, 2020 at 12:28:23AM +0200, freebsd@sysctl.cz wrote: >> > > Hi, >> > > I tried debug with gdb for linux emulation >> > > and have issue with kernel panic. >> > > >> > > kldload linux64.ko >> > > gdb ./Discord or other linux binary >> > > >> > > Fatal trap 12: page fault while in kernel mode >> > > cpuid = 3; apic id = 03 >> > > fault virtual address = 0x18 >> > > fault code = supervisor read data, page not present >> > > instruction pointer = 0x20:0xffffffff82f5b682 >> > > stack pointer = 0x28:0xfffffe00691fd980 >> > > frame pointer = 0x28:0xfffffe00691fd9e0 >> > > code segment = base 0x0, limit 0xfffff, type 0x1b >> > > = DPL 0, pres 1, long 1, def32 0, gran 1 >> > > processor eflags = interrupt enabled, resume, IOPL = 0 >> > > current process = 17392 (fish) >> > > trap number = 12 >> > > panic: page fault >> > > cpuid = 3 >> > > time = 1589132677 >> > > KDB: stack backtrace: >> > > #0 0xffffffff80c1d2f7 at kdb_backtrace+0x67 >> > > #1 0xffffffff80bd062d at vpanic+0x19d >> > > #2 0xffffffff80bd0483 at panic+0x43 >> > > #3 0xffffffff810a7dcc at trap_fatal+0x39c >> > > #4 0xffffffff810a7e19 at trap_pfault+0x49 >> > > #5 0xffffffff810a740f at trap+0x29f >> > > #6 0xffffffff81081bdc at calltrap+0x8 >> > > #7 0xffffffff82f503d1 at linux_thread_detach+0x21 >> > Show the line number for linux_thread_detach+0x21. >> > Or better, compile with INVARIANTS, it should fire an assertion. >> > Then get a core dump. >> > >> > > #8 0xffffffff80be5acf at thread_suspend_check+0x41f >> > > #9 0xffffffff80c32ed9 at ast+0x3b9 >> > > #10 0xffffffff810850e9 at doreti_ast+0x1f >> > > Uptime: 2h56m24s >> > > Dumping 1146 out of 8042 >> > > MB:..2%..12%..21%..31%..41%..51%..62%..72%..81%..91%---<>--- >> > > Copyright (c) 1992-2019 The FreeBSD Project. >> > > >> > > GNU gdb (GDB) 9.1 [GDB v9.1 for FreeBSD] >> > > Copyright (C) 2020 Free Software Foundation, Inc. >> > > License GPLv3+: GNU GPL version 3 or later >> > > >> > > This is free software: you are free to change and redistribute it. >> > > There is NO WARRANTY, to the extent permitted by law. >> > > Type "show copying" and "show warranty" for details. >> > > This GDB was configured as "x86_64-portbld-freebsd12.1". >> > > Type "show configuration" for configuration details. >> > > For bug reporting instructions, please see: >> > > . >> > > Find the GDB manual and other documentation resources online at: >> > > . >> > > >> > > For help, type "help". >> > > Type "apropos word" to search for commands related to "word"... >> > > Reading symbols from /boot/kernel/kernel... >> > > (No debugging symbols found in /boot/kernel/kernel) >> > > 0xffffffff80c01eda in sched_switch () >> > > (kgdb) >> > > (kgdb) >> > > (kgdb) bt >> > > #0 0xffffffff80c01eda in sched_switch () >> > > #1 0xffffffff80bdbfa2 in mi_switch () >> > > #2 0xffffffff80c2bb75 in sleepq_catch_signals () >> > > #3 0xffffffff80c2be64 in sleepq_timedwait_sig () >> > > #4 0xffffffff80bdb9a5 in _sleep () >> > > #5 0xffffffff80bf1ee3 in umtxq_sleep () >> > > #6 0xffffffff80bf1c90 in do_wait () >> > > #7 0xffffffff80bef8fe in __umtx_op_wait_uint_private () >> > > #8 0xffffffff810a8984 in amd64_syscall () >> > > #9 >> > > #10 0x000000080974dedc in ?? () >> > > Backtrace stopped: Cannot access memory at address 0x7fffffffddc8 >> > > >> > > I have now kernel without debug symbols. >> > > >> > > M. >> > > _______________________________________________ >> > > freebsd-emulation@freebsd.org mailing list >> > > https://lists.freebsd.org/mailman/listinfo/freebsd-emulation >> > > To unsubscribe, send any mail to >> > > "freebsd-emulation-unsubscribe@freebsd.org" >> > _______________________________________________ >> > freebsd-hackers@freebsd.org mailing list >> > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> > To unsubscribe, send any mail to >> > "freebsd-hackers-unsubscribe@freebsd.org" >> >> >> >> Hi konstantin, >> I have good news, now we can look detail >> >> (kgdb) bt >> #0 __curthread () at /usr/src/sys/amd64/include/pcpu.h:234 >> #1 doadump (textdump=) at >> /usr/src/sys/kern/kern_shutdown.c:371 >> #2 0xffffffff80bd0228 in kern_reboot (howto=260) at >> /usr/src/sys/kern/kern_shutdown.c:451 >> #3 0xffffffff80bd0689 in vpanic (fmt=, ap=> out>) >> at /usr/src/sys/kern/kern_shutdown.c:877 >> #4 0xffffffff80bd0483 in panic (fmt=) at >> /usr/src/sys/kern/kern_shutdown.c:804 >> #5 0xffffffff810a7dcc in trap_fatal (frame=0xfffffe00634e58c0, >> eva=24) at >> /usr/src/sys/amd64/amd64/trap.c:943 >> #6 0xffffffff810a7e19 in trap_pfault (frame=0xfffffe00634e58c0, >> usermode=0) >> at /usr/src/sys/amd64/amd64/trap.c:767 >> #7 0xffffffff810a740f in trap (frame=0xfffffe00634e58c0) at >> /usr/src/sys/amd64/amd64/trap.c:443 >> #8 >> #9 release_futexes (td=, em=0x0) at >> /usr/src/sys/compat/linux/linux_futex.c:1283 >> #10 0xffffffff82f503d1 in linux_thread_detach (td=0xfffff8014bd935e0) >> at >> /usr/src/sys/compat/linux/linux_fork.c:466 >> #11 0xffffffff80be5acf in thread_suspend_check (return_instead=0) at >> /usr/src/sys/kern/kern_thread.c:1010 >> #12 0xffffffff80c32ed9 in ast (framep=0xfffffe00634e5ac0) at >> /usr/src/sys/kern/subr_trap.c:342 >> #13 0xffffffff810850e9 in doreti_ast () at >> /usr/src/sys/amd64/amd64/exception.S:1149 >> #14 0x0000000800bb7008 in ?? () >> #15 0x000000000000000f in ?? () >> #16 0x0000000000000000 in ?? () >> (kgdb) list 0xffffffff82f503d1 >> Function "0xffffffff82f503d1" not defined. >> (kgdb) list *0xffffffff82f503d1 >> 0xffffffff82f503d1 is in linux_thread_detach >> (/usr/src/sys/compat/linux/linux_fork.c:468). >> warning: Source file is more recent than executable. > This indicates that your source potentially does not match the kernel. > And indeed as seen below, if panic occured on line 468, then it should > be due to em dereference, which should be 0. But then, > release_futexes() > alse dereference em and should cause the same trap earlier. > >> 463 >> 464 LINUX_CTR1(thread_detach, "thread(%d)", em->em_tid); >> 465 >> 466 release_futexes(td, em); >> 467 >> 468 child_clear_tid = em->child_clear_tid; >> 469 >> 470 if (child_clear_tid != NULL) { >> 471 >> 472 LINUX_CTR2(thread_detach, "thread(%d) %p", >> (kgdb) > So you did not recompiled with INVARIANTS ? > > It might be easier if you provide me with a self-contained tarball of > small > linux binary and all required libraries which reproduce the panic. > > If not, ensure that the kernel binary is consistent with the sources, > that INVARIANTS are enabled, and provide backtraces from gdb for all > threads of the paniced process. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to > "freebsd-hackers-unsubscribe@freebsd.org" Hello konstantin, i have now 12.1 p5 generic kernel and cannot replicate this kernel panic. M.F. From owner-freebsd-hackers@freebsd.org Fri May 15 16:45:41 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 30B2F2FA27C for ; Fri, 15 May 2020 16:45:41 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49NvRR46xFz45cD for ; Fri, 15 May 2020 16:45:39 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id 04FGjUlE065359 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 15 May 2020 19:45:33 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 04FGjUlE065359 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id 04FGjUgs065358; Fri, 15 May 2020 19:45:30 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 15 May 2020 19:45:30 +0300 From: Konstantin Belousov To: freebsd@sysctl.cz Cc: Freebsd hackers Subject: Re: Debug linux binary with enable linux emulation Message-ID: <20200515164530.GC46537@kib.kiev.ua> References: <24f30eaa0597d79ddadc10d6f993f2a0@sysctl.cz> <20200511115656.GF68906@kib.kiev.ua> <67eed7f18b68f67ff04f628c4c367535@sysctl.cz> <20200512174935.GK68906@kib.kiev.ua> <0fd224d0e4bc643ec8980f2cd71d87c2@sysctl.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0fd224d0e4bc643ec8980f2cd71d87c2@sysctl.cz> X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on tom.home X-Rspamd-Queue-Id: 49NvRR46xFz45cD X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kostikbel@gmail.com) smtp.mailfrom=kostikbel@gmail.com X-Spamd-Result: default: False [-2.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; IP_SCORE(0.00)[ip: (-3.06), ipnet: 2001:470::/32(-4.10), asn: 6939(-3.15), country: US(-0.05)]; 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_COUNT_TWO(0.00)[2]; FREEMAIL_ENVFROM(0.00)[gmail.com]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 16:45:41 -0000 On Fri, May 15, 2020 at 06:22:54PM +0200, freebsd@sysctl.cz wrote: > i have now 12.1 p5 generic kernel and cannot replicate this kernel panic. > M.F. And what was the version where it occurred ? From owner-freebsd-hackers@freebsd.org Fri May 15 17:14:11 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B47062FAE73 for ; Fri, 15 May 2020 17:14:11 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ultimatedns.net", Issuer "Let's Encrypt Authority X3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 49Nw4M23s9z482p for ; Fri, 15 May 2020 17:14:10 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (localhost [IPv6:0:0:0:0:0:0:0:1]) by udns.ultimatedns.net (8.15.2/8.15.2) with ESMTPS id 04FHEIr3055632 (version=TLSv1.2 cipher=DHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 15 May 2020 10:14:25 -0700 (PDT) (envelope-from bsd-lists@BSDforge.com) X-Mailer: Cypht MIME-Version: 1.0 Cc: "Rodney W. Grimes" , FreeBSD Hackers , Diane Bruce In-Reply-To: <20200515150627.GY82984@trajan.stk.cx> From: Chris Reply-To: bsd-lists@BSDforge.com To: Subject: Re: [HEADSUP] Disallowing read() of a directory fd Date: Fri, 15 May 2020 10:14:24 -0700 Message-Id: <02cb48c24a3d010dab13974680dc3d16@udns.ultimatedns.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 49Nw4M23s9z482p X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-1.68 / 15.00]; NEURAL_HAM_MEDIUM(-0.69)[-0.690,0]; NEURAL_HAM_LONG(-0.99)[-0.991,0]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US]; local_wl_ip(0.00)[24.113.41.81] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 17:14:11 -0000 On Fri, 15 May 2020 17:06:27 +0200 arne@Steinkamm=2ECOM said > On Fri, May 15, 2020 at 10:48:15AM -0400, Diane Bruce wrote: > > All I have to say on this noisy bikeshed is, let's resurrect the mkdir > > bug of V7 because it's tradition and the BSD way and history and stuff=2E > > (I only expect a few of you to remember this one=2E) >=20 > Oh, this "bug" was alive until Sys V 3=2E2 times=2E=2E=2E >=20 > Implementing mkdir as library function without a syscall wasn't a good id= ea=2E > ken and dmr saw no reason to implement mkdir as atomic operation=2E > So it was easy, even with a shell script, to jump between the > mknod(2) and the chown(2) to replace the directory node with a symlink to > /etc/passwd=2E >=20 > This was from a todays point of view a stupid mistake=2E Reading a director= y > node > is lightyears away from "a stupid mistake"=2E >=20 > Make it switchable with a sysctl switch=2E=2E=2E would be the best of both worl= ds=2E So long as it were not read only, might be acceptable=2E But given the potent= ial gains for all this, are trivial at best=2E Why was this proposal not dropped? It's spooling up a massive buffer, for little, to no significant value=2E Move on to something of _actual_ importance -- *please*=2E --Chris >=20 > =2E//=2E Arne >=20 > --=20 > Arne Steinkamm | Home: Mail: arnesteinkammcom > Tel=2E: +49=2E89=2E21031004 | Gr=C3=B6benbachweg 13, 82178 Puchheim, GERMANY From owner-freebsd-hackers@freebsd.org Fri May 15 17:26:39 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 7F7CF2FB28D for ; Fri, 15 May 2020 17:26:39 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49NwLl2cSPz490y; Fri, 15 May 2020 17:26:39 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (unknown [127.0.1.132]) (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 freefall.freebsd.org (Postfix) with ESMTPS id 12DFD1E15B; Fri, 15 May 2020 17:26:39 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id E589E1FC39; Fri, 15 May 2020 17:26:37 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id dUie0udqWBw2; Fri, 15 May 2020 17:26:35 +0000 (UTC) Subject: Re: [HEADSUP] Disallowing read() of a directory fd DKIM-Filter: OpenDKIM Filter v2.10.3 mail.xzibition.com 49B031FC2F To: bsd-lists@BSDforge.com Cc: FreeBSD Hackers References: <02cb48c24a3d010dab13974680dc3d16@udns.ultimatedns.net> From: Bryan Drewery Autocrypt: addr=bdrewery@FreeBSD.org; prefer-encrypt=mutual; keydata= mQENBFJphmsBCADiFgmS4bIzwZijrS31SjEMzg+n5zNellgM+HkShwehpqCiyhXdWrvH6dTZ a6u50pbUIX7doTR7W7PQHCjCTqtpwvcj0eulZva+iHFp+XrbgSFHn+VVXgkYP2MFySyZRFab D2qqzJBEJofhpv4HvY6uQI5K99pMqKr1Z/lHqsijYYu4RH2OfwB5PinId7xeldzWEonVoCr+ rfxzO/UrgA6v/3layGZcKNHFjmc3NqoN1DXtdaEHqtjIozzbndVkH6lkFvIpIrI6i5ox8pwp VxsxLCr/4Musd5CWgHiet5kSw2SzNeA8FbxdLYCpXNVu+uBACEbCUP+CSNy3NVfEUxsBABEB AAG0JEJyeWFuIERyZXdlcnkgPGJkcmV3ZXJ5QEZyZWVCU0Qub3JnPokBVwQTAQoAQQIbAwUL CQgHAwUVCgkICwUWAwIBAAIeAQIXgAIZARYhBPkXPLLDqup6XIofCTXXcbtuRpfPBQJb5hLu BQkNPvODAAoJEDXXcbtuRpfP9rMH/3f7cfX5rzyEV5QNfV/wS4jFukLoPZ4+nCM/TKxH3pEX 2bLbeQbkk6La8cueQ5Lpoht5XFZ18Y5TbMittngltrlNzoDD0h9are24OkDFGim3afJU7tkj IGQa1if+re+vI5BhzYwRhj0oKXzBi39M5oePd3L1dXfx83rg2FPyZBdIejsz6fR74T3JVkbd 6k2l5/3Zk2uiNMy+eBfDRgYE1E6CP28kV0nCeGKZgSVso0kGUUHud7voKqGVpMvbd0mE4pp4 PE5YJaFPjrll9miaDAvdU8LGIq5n6+aXPLKoQ/QNl6mg6ifgI6FfKILOkTizLW8E5PBSNnCm NapQ55yjm125AQ0EUmmGawEIAKJUU9+Q19oW1RK5jTf3m56j+szIc8Y9DaLC8REUKl4UZJBK BqCl6c0cukVApOD92XoU6hJPm2rLEyp/IcYcPPNTnVu8D8h9oag2L8EiFN7+2hk0xG+lwjc8 uOIZycme7AIJsBU4AZ1v63lxm2k104hwpiatgbe71GIGl7p1MX6ousP/wGzXCOF25Dx9w02C eRe7zEMfhnFjSUhzdCC9han2+KaVB7qIqNR3b8NfbwRNlwPmHqlhXffUow9OsQjSnTK8WKNR lx7xzVccXIvWP2wECFrmqmzMmXpSrmIuiWEpFwZ9x2a0Pva8dCNRiCVTK51IlRXKjaAxiN1u IUrMm6UAEQEAAYkBPAQYAQoAJgIbDBYhBPkXPLLDqup6XIofCTXXcbtuRpfPBQJb5hL4BQkN PvONAAoJEDXXcbtuRpfPCjcH/ivBsOpdpebpgLizSNU5/X4yWN5Aixsc9VBnQhGKAKnMINJQ VMpA55sD2JSPwloXYM/B3qyPJRS/9cwIuX5LDNKKOZU3Qp+TzleynM15/xea14orWYRGRict YHBM3Cnqp7OD8K6Q1uhs0fTxyJP7PZ/G0+7Corlf1DlHhDt6C2HldRPFvAvAgl6sR9Wzgcb7 rzub2HVtbJgl6YHbgyAG7x9NpXFqzx1JLAMdpt2DIYwoi+oMdRQlBIwNuKjQjCGzuXHandd3 kGvBAsyJpQ+coEep9UzwANaV28cXrFr2R4FSOcR50rBA2Nh/vqUYfpsvBvJlwuKAoV1djVHa ihNeL5E= Organization: FreeBSD Message-ID: <3e2d8e95-69fa-980e-d9c2-3ec5db6aa22c@FreeBSD.org> Date: Fri, 15 May 2020 10:26:34 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <02cb48c24a3d010dab13974680dc3d16@udns.ultimatedns.net> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="i9s7C225yIhdKxmJyW77EpGq7jwUOLyd7" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 17:26:39 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --i9s7C225yIhdKxmJyW77EpGq7jwUOLyd7 Content-Type: multipart/mixed; boundary="nUn1rGlZI4y6zC12EaX0B3sVIXQL7QYNK"; protected-headers="v1" From: Bryan Drewery To: bsd-lists@BSDforge.com Cc: FreeBSD Hackers Message-ID: <3e2d8e95-69fa-980e-d9c2-3ec5db6aa22c@FreeBSD.org> Subject: Re: [HEADSUP] Disallowing read() of a directory fd References: <02cb48c24a3d010dab13974680dc3d16@udns.ultimatedns.net> In-Reply-To: <02cb48c24a3d010dab13974680dc3d16@udns.ultimatedns.net> --nUn1rGlZI4y6zC12EaX0B3sVIXQL7QYNK Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 5/15/2020 10:14 AM, Chris wrote: > It's spooling up a massive buffer, for little, to no significant value.= If you don't want community discussions in your email then unsubscribe. Otherwise please be constructive. --=20 Regards, Bryan Drewery --nUn1rGlZI4y6zC12EaX0B3sVIXQL7QYNK-- --i9s7C225yIhdKxmJyW77EpGq7jwUOLyd7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAEBCgB9FiEE+Rc8ssOq6npcih8JNddxu25Gl88FAl6+0MpfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEY5 MTczQ0IyQzNBQUVBN0E1QzhBMUYwOTM1RDc3MUJCNkU0Njk3Q0YACgkQNddxu25G l89sOwgA2gz6e81/FwYILII5x28BEncecz1xJb03QBQD/isVE86fIhnrqHRHQGg6 MMsopA4XTiqL2PxKJSFAB8ZhOkUHzDu9PR2mHZzyRT5wB5x/lX7R09upjDA9yL+Z 0oZwR27X7qcnx/dnMIIt8WXICVOlzubzzJURIhVO7xoeZ7Oibptodb4qqpvoffCI 5iEilcPeD9X08tNhATTQGJ1jHpxADbfyF969zFnjb8wQi9xakaEGZl2OflxsFUbB D7eAiVRDekxOk1OkkinGxKPIyPte4bQIFRM5K9uB/1/TN5de1hAXTIMSL2QH8Mqu oJe9XiqQOk4QyY/1TTPYhzULC4CLOw== =ZrSI -----END PGP SIGNATURE----- --i9s7C225yIhdKxmJyW77EpGq7jwUOLyd7-- From owner-freebsd-hackers@freebsd.org Fri May 15 17:34:14 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 936232FB59D for ; Fri, 15 May 2020 17:34:14 +0000 (UTC) (envelope-from jim@netgate.com) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 49NwWV27qsz49lX for ; Fri, 15 May 2020 17:34:14 +0000 (UTC) (envelope-from jim@netgate.com) Received: by mailman.nyi.freebsd.org (Postfix) id 478F92FB59C; Fri, 15 May 2020 17:34:14 +0000 (UTC) Delivered-To: hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 474DC2FB59B for ; Fri, 15 May 2020 17:34:14 +0000 (UTC) (envelope-from jim@netgate.com) Received: from mail-ot1-x32a.google.com (mail-ot1-x32a.google.com [IPv6:2607:f8b0:4864:20::32a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) 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 49NwWT43MYz49lT for ; Fri, 15 May 2020 17:34:13 +0000 (UTC) (envelope-from jim@netgate.com) Received: by mail-ot1-x32a.google.com with SMTP id a68so2503548otb.10 for ; Fri, 15 May 2020 10:34:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=dgm9xRRsSYlBUD34jO9rOYB7RhKEiYIqFoVgqBRIL/I=; b=a5xPImezNQ6cvlh65ialtFPPzygvfDCvWK61g+khnDp92+jbO9oJnFOHaFzYU/gUh7 ow+oDsayyDnU+vO8imNEVlSomwEtAmuWVyeGihnjouqAUY59yUYyfkl8Oh4ZY98N6eA7 Uifru/d5XIaLJqLwZAdZo9WaJXTgOa5/UXr4J3LQtA3fFNqdsuHLAaqTgsuEatjFeZpo M4MShv7HNUUAXdhXbVAUAsqdlr7qk5nE0qHSTziIdJPVdW+vKmrImo8g8TkyxOL1VdrK t9BXDa12cFPmN48YqBWXZftTQECP3/KOYeJtVTp1LlxrpPImWFmrybLqAT2swRwYddJE g9IQ== X-Gm-Message-State: AOAM532lL9c3P2xmoBmnu9aphScC7RJXkhwdFPbEfgt1GUiusGdjYvUV G/E7KJ4wqsyhHkl5SeQvwGB+yQ== X-Google-Smtp-Source: ABdhPJz5hgUejUUzb1pcoxSVhKQxjaomBE2OKs19nA3EHrpUnt+rp2680Mg4eEwfQctoS3OvgLtvVg== X-Received: by 2002:a05:6830:1d88:: with SMTP id y8mr3265310oti.255.1589564052280; Fri, 15 May 2020 10:34:12 -0700 (PDT) Received: from [172.21.0.25] (66-196-7-151.dyn.grandenetworks.net. [66.196.7.151]) by smtp.gmail.com with ESMTPSA id w14sm742888oou.46.2020.05.15.10.34.11 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 May 2020 10:34:11 -0700 (PDT) From: Jim Thompson Message-Id: <9C0CCC6D-BA3A-4068-BC3B-5B40E7C668E1@netgate.com> Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: [HEADSUP] Disallowing read() of a directory fd Date: Fri, 15 May 2020 12:34:10 -0500 In-Reply-To: <35501.1589529102@critter.freebsd.dk> Cc: Kyle Evans , Alan Somers , "Julian H. Stacey" , "freebsd-arch@freebsd.org" , "freebsd-hackers@freebsd.org" To: Poul-Henning Kamp References: <202005142017.04EKH0aA093503@fire.js.berklix.net> <33549.1589488226@critter.freebsd.dk> <35501.1589529102@critter.freebsd.dk> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 49NwWT43MYz49lT X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.30 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_ALLOW(-0.20)[netgate.com:s=google]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[hackers@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCPT_COUNT_FIVE(0.00)[6]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[netgate.com:+]; DMARC_POLICY_ALLOW(-0.50)[netgate.com,quarantine]; RCVD_IN_DNSWL_NONE(0.00)[a.2.3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; IP_SCORE(-1.80)[ip: (-8.17), ipnet: 2607:f8b0::/32(-0.33), asn: 15169(-0.42), country: US(-0.05)]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 17:34:14 -0000 > On May 15, 2020, at 2:51 AM, Poul-Henning Kamp = wrote: >=20 > Summary: I'm perfectly fine with read(2) returning error on a > directory *under normal circumstances*, and I think it makes good > sense by protecting a lot of terminals from a lot of binary > garbage. >=20 > But there is absolutely no reason to make it *impossible* for > a competent root to do what competent roots do. In the large, I=E2=80=99m in agreement that read(2) on a directory = should work, at least for if (suser()), but the last sentence here would = allow root to write(2) a directory, too, and that hasn=E2=80=99t been = true for Unix for over 40 years, if ever. Jim From owner-freebsd-hackers@freebsd.org Fri May 15 17:36:55 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id F39A52FB745 for ; Fri, 15 May 2020 17:36:55 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ultimatedns.net", Issuer "Let's Encrypt Authority X3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 49NwZb5f8Lz4B2f; Fri, 15 May 2020 17:36:55 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (localhost [IPv6:0:0:0:0:0:0:0:1]) by udns.ultimatedns.net (8.15.2/8.15.2) with ESMTPS id 04FHbCQ9056089 (version=TLSv1.2 cipher=DHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 15 May 2020 10:37:18 -0700 (PDT) (envelope-from bsd-lists@BSDforge.com) X-Mailer: Cypht MIME-Version: 1.0 Cc: FreeBSD Hackers , In-Reply-To: <3e2d8e95-69fa-980e-d9c2-3ec5db6aa22c@FreeBSD.org> From: Chris Reply-To: bsd-lists@BSDforge.com To: Bryan Drewery Subject: Re: [HEADSUP] Disallowing read() of a directory fd Date: Fri, 15 May 2020 10:37:18 -0700 Message-Id: <4f049049bf1c169a3a41a66287727437@udns.ultimatedns.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 49NwZb5f8Lz4B2f X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-1.58 / 15.00]; NEURAL_HAM_MEDIUM(-0.60)[-0.598,0]; NEURAL_HAM_LONG(-0.98)[-0.978,0]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US]; local_wl_ip(0.00)[24.113.41.81] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 17:36:56 -0000 On Fri, 15 May 2020 10:26:34 -0700 Bryan Drewery bdrewery@FreeBSD=2Eorg said > On 5/15/2020 10:14 AM, Chris wrote: > > It's spooling up a massive buffer, for little, to no significant value=2E >=20 > If you don't want community discussions in your email then unsubscribe=2E > Otherwise please be constructive=2E I believed my assertion was constructive=2E I greatly appreciate that Kevin is so interested in spending his valuable time on the project=2E But my view on this, is that the gains for this proposal are trivial, and that his valuable time might be better spent elsewhere=2E All the best=2E --Chris >=20 > --=20 > Regards, > Bryan Drewery From owner-freebsd-hackers@freebsd.org Fri May 15 17:41:45 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id EF8272FBA13; Fri, 15 May 2020 17:41:45 +0000 (UTC) (envelope-from freebsd@sysctl.cz) Received: from wes1-so2.wedos.net (wes1-so2.wedos.net [46.28.106.45]) (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 49Nwh86xmDz4Bbw; Fri, 15 May 2020 17:41:44 +0000 (UTC) (envelope-from freebsd@sysctl.cz) Received: from webmail.wedos.net (wes1-wm3.wedos.net [46.28.106.84]) by wes1-so2.wedos.net (Postfix) with ESMTPSA id 49Nwh10VRHzhm; Fri, 15 May 2020 19:41:37 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 15 May 2020 19:41:36 +0200 From: freebsd@sysctl.cz To: Konstantin Belousov Cc: Freebsd hackers , owner-freebsd-hackers@freebsd.org Subject: Re: Debug linux binary with enable linux emulation In-Reply-To: <20200515164530.GC46537@kib.kiev.ua> References: <24f30eaa0597d79ddadc10d6f993f2a0@sysctl.cz> <20200511115656.GF68906@kib.kiev.ua> <67eed7f18b68f67ff04f628c4c367535@sysctl.cz> <20200512174935.GK68906@kib.kiev.ua> <0fd224d0e4bc643ec8980f2cd71d87c2@sysctl.cz> <20200515164530.GC46537@kib.kiev.ua> Message-ID: X-Sender: freebsd@sysctl.cz User-Agent: Roundcube Webmail/1.2.4 X-Rspamd-Queue-Id: 49Nwh86xmDz4Bbw X-Spamd-Bar: +++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd@sysctl.cz has no SPF policy when checking 46.28.106.45) smtp.mailfrom=freebsd@sysctl.cz X-Spamd-Result: default: False [3.91 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; IP_SCORE(1.04)[ipnet: 46.28.104.0/21(1.37), asn: 197019(3.75), country: CZ(0.09)]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[sysctl.cz]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.97)[0.969,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(1.00)[0.999,0]; FROM_NO_DN(0.00)[]; R_SPF_NA(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:197019, ipnet:46.28.104.0/21, country:CZ]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 17:41:46 -0000 Dne 2020-05-15 18:45, Konstantin Belousov napsal: > On Fri, May 15, 2020 at 06:22:54PM +0200, freebsd@sysctl.cz wrote: >> i have now 12.1 p5 generic kernel and cannot replicate this kernel >> panic. >> M.F. > And what was the version where it occurred ? > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to > "freebsd-hackers-unsubscribe@freebsd.org" Version was FreeBSD 12.1-RELEASE-p3 GENERIC Architecture: amd64 Architecture Version: 2 Dump Length: 1202487296 Blocksize: 512 Compression: none Dumptime: Sun May 10 19:44:37 2020 Hostname: Magic: FreeBSD Kernel Dump Version String: FreeBSD 12.1-RELEASE-p3 GENERIC Panic String: page fault Dump Parity: 3631849229 Bounds: 2 May 10 19:43:33 kernel: pid 19891 (Discord), jid 0, uid 1001: exited on signal 5 (core dumped) May 10 19:43:35 kernel: pid 23929 (Discord), jid 0, uid 1001: exited on signal 5 (core dumped) May 10 19:45:17 syslogd: kernel boot file is /boot/kernel/kernel May 10 19:45:17 kernel: May 10 19:45:17 syslogd: last message repeated 1 times May 10 19:45:17 kernel: Fatal trap 12: page fault while in kernel mode May 10 19:45:17 kernel: cpuid = 3; apic id = 03 May 10 19:45:17 kernel: fault virtual address = 0x18 May 10 19:45:17 kernel: fault code = supervisor read data, page not present May 10 19:45:17 kernel: instruction pointer = 0x20:0xffffffff82f5b682 May 10 19:45:17 kernel: stack pointer = 0x28:0xfffffe00691fd980 May 10 19:45:17 kernel: frame pointer = 0x28:0xfffffe00691fd9e0 May 10 19:45:17 kernel: code segment = base 0x0, limit 0xfffff, type 0x1b May 10 19:45:17 kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 May 10 19:45:17 kernel: processor eflags = interrupt enabled, resume, IOPL = 0 May 10 19:45:17 kernel: current process = 17392 (fish) May 10 19:45:17 kernel: trap number = 12 May 10 19:45:17 kernel: panic: page fault May 10 19:45:17 kernel: cpuid = 3 May 10 19:45:17 kernel: time = 1589132677 May 10 19:45:17 kernel: KDB: stack backtrace: May 10 19:45:17 kernel: #0 0xffffffff80c1d2f7 at kdb_backtrace+0x67 May 10 19:45:17 kernel: #1 0xffffffff80bd062d at vpanic+0x19d May 10 19:45:17 kernel: #2 0xffffffff80bd0483 at panic+0x43 May 10 19:45:17 kernel: #3 0xffffffff810a7dcc at trap_fatal+0x39c May 10 19:45:17 kernel: #4 0xffffffff810a7e19 at trap_pfault+0x49 May 10 19:45:17 kernel: #5 0xffffffff810a740f at trap+0x29f May 10 19:45:17 kernel: #6 0xffffffff81081bdc at calltrap+0x8 May 10 19:45:17 kernel: #7 0xffffffff82f503d1 at linux_thread_detach+0x21 May 10 19:45:17 kernel: #8 0xffffffff80be5acf at thread_suspend_check+0x41f May 10 19:45:17 kernel: #9 0xffffffff80c32ed9 at ast+0x3b9 May 10 19:45:17 kernel: #10 0xffffffff810850e9 at doreti_ast+0x1f May 10 19:45:17 kernel: Uptime: 2h56m24s May 10 19:45:17 kernel: Dumping 1146 out of 8042 MB:..2%..12%..21%..31%..41%..51%..62%..72%..81%..91%---<>--- May 10 19:45:17 kernel: Copyright (c) 1992-2019 The FreeBSD Project. May 10 19:45:17 kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 May 10 19:45:17 kernel: The Regents of the University of California. All rights reserved. May 10 19:45:17 kernel: FreeBSD is a registered trademark of The FreeBSD Foundation. May 10 19:45:17 kernel: FreeBSD 12.1-RELEASE-p3 GENERIC amd64 May 10 19:45:17 kernel: FreeBSD clang version 8.0.1 (tags/RELEASE_801/final 366581) (based on LLVM 8.0.1) May 10 19:45:17 kernel: VT(vga): resolution 640x480 May 10 19:45:17 kernel: CPU: Intel(R) Core(TM) i7-2670QM CPU @ 2.20GHz (2195.07-MHz K8-class CPU) May 10 19:45:17 kernel: Origin="GenuineIntel" Id=0x206a7 Family=0x6 Model=0x2a Stepping=7 May 10 19:45:17 kernel: Features=0xbfebfbff May 10 19:45:17 kernel: Features2=0x1fbae3bf May 10 19:45:17 kernel: AMD Features=0x28100800 May 10 19:45:17 kernel: AMD Features2=0x1 May 10 19:45:17 kernel: XSAVE Features=0x1 May 10 19:45:17 kernel: VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID From owner-freebsd-hackers@freebsd.org Fri May 15 17:50:09 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B91CE2FBEDF for ; Fri, 15 May 2020 17:50:09 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-il1-f179.google.com (mail-il1-f179.google.com [209.85.166.179]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) 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 49Nwsr5N60z4CJq for ; Fri, 15 May 2020 17:50:08 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-il1-f179.google.com with SMTP id q10so3440391ile.0 for ; Fri, 15 May 2020 10:50:08 -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=Ez/SLyrOgfpo3/NAtV7IRm6bJ9F1C0fcTHpIjg1lgwo=; b=KwIlJtW6X2ps+3mlfh7GLV9BDtfDNw50LOH376baNaOKxkhNI9koiw5PgFtupg6/vW +/Eg0Zcvu3lMHJOVLfbzQO+az6pDjFCzo1M4KHSoO5cAUtsvHX+r66wj2RwStfeNs1J2 YqswQCAVF5h+IQkx+VMdNH3sq+wwlASrHo1zM8W4253gQbg7vB8lrtNUsw7vvICXSbt6 ms2/icI5XtT5CMXM8LyNow67lBKcF3FgN2rladPxE81UOW/J82N/JDEJCbw1TLonMom5 Rn5Jf4auSwYJ6urhj78tcP9gqzovlbDX7xGUFC4UH4VZCmXeUeO8UcMxlWA72Smzis1G V0Lg== X-Gm-Message-State: AOAM530J+rAqcRMwqGdXjhhY/QMdPuJR5SgYnk5tZJUw5F7bac7Z6Zyy DDhzgzUMQ4GpPv2LLg3eNjlUoFdRVwfMXwM4GhtJzrbFroA= X-Google-Smtp-Source: ABdhPJyhuOU+H3tcJj0AuNQMYJG/wzeyHaiR00jowyxKPLZY6Bh4sUpBgm7VzmenYeFpYzb28MVL1M3JY0ZSUI4avww= X-Received: by 2002:a92:c952:: with SMTP id i18mr4776036ilq.100.1589565007503; Fri, 15 May 2020 10:50:07 -0700 (PDT) MIME-Version: 1.0 References: <20200515150627.GY82984@trajan.stk.cx> <02cb48c24a3d010dab13974680dc3d16@udns.ultimatedns.net> In-Reply-To: <02cb48c24a3d010dab13974680dc3d16@udns.ultimatedns.net> From: Ed Maste Date: Fri, 15 May 2020 13:49:54 -0400 Message-ID: Subject: Re: [HEADSUP] Disallowing read() of a directory fd To: bsd-lists@bsdforge.com Cc: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 49Nwsr5N60z4CJq X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.166.179 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [-3.43 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[179.166.85.209.list.dnswl.org : 127.0.5.0]; IP_SCORE(-1.43)[ip: (-6.28), ipnet: 209.85.128.0/17(-0.39), asn: 15169(-0.42), country: US(-0.05)]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[179.166.85.209.rep.mailspike.net : 127.0.0.17]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 17:50:09 -0000 On Fri, 15 May 2020 at 13:14, Chris wrote: > > But given the potential > gains for all this, are trivial at best. Some benefits of this change have already been discussed: 1. It would have prevented, or at least significantly blunted, the security issue described in FreeBSD-SA-19:10.ufs. 2. It avoids problems caused by application assumptions. On the other hand, arguments for allowing reads of directories: 1. It's always been that way. 2. File system developers and experts may use the ability for certain special or unusual actions. Making the change with a sysctl to control still allows the special case use, and I'm glad that Kyle spent the time on this change. From owner-freebsd-hackers@freebsd.org Fri May 15 18:00:21 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 6167D2FC438; Fri, 15 May 2020 18:00:21 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49Nx5c4jDFz4D5y; Fri, 15 May 2020 18:00:20 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id 04FI06HK083425 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 15 May 2020 21:00:10 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 04FI06HK083425 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id 04FI06Id083424; Fri, 15 May 2020 21:00:06 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 15 May 2020 21:00:06 +0300 From: Konstantin Belousov To: freebsd@sysctl.cz Cc: Freebsd hackers , owner-freebsd-hackers@freebsd.org Subject: Re: Debug linux binary with enable linux emulation Message-ID: <20200515180006.GD46537@kib.kiev.ua> References: <24f30eaa0597d79ddadc10d6f993f2a0@sysctl.cz> <20200511115656.GF68906@kib.kiev.ua> <67eed7f18b68f67ff04f628c4c367535@sysctl.cz> <20200512174935.GK68906@kib.kiev.ua> <0fd224d0e4bc643ec8980f2cd71d87c2@sysctl.cz> <20200515164530.GC46537@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on tom.home X-Rspamd-Queue-Id: 49Nx5c4jDFz4D5y X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kostikbel@gmail.com) smtp.mailfrom=kostikbel@gmail.com X-Spamd-Result: default: False [-2.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[gmail.com]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all:c]; IP_SCORE_FREEMAIL(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; IP_SCORE(0.00)[ip: (-3.06), ipnet: 2001:470::/32(-4.10), asn: 6939(-3.15), country: US(-0.05)]; 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_COUNT_TWO(0.00)[2]; FREEMAIL_ENVFROM(0.00)[gmail.com]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 18:00:21 -0000 On Fri, May 15, 2020 at 07:41:36PM +0200, freebsd@sysctl.cz wrote: > Dne 2020-05-15 18:45, Konstantin Belousov napsal: > > On Fri, May 15, 2020 at 06:22:54PM +0200, freebsd@sysctl.cz wrote: > > > i have now 12.1 p5 generic kernel and cannot replicate this kernel > > > panic. > > > M.F. > > And what was the version where it occurred ? > > _______________________________________________ > > freebsd-hackers@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > To unsubscribe, send any mail to > > "freebsd-hackers-unsubscribe@freebsd.org" > > Version was FreeBSD 12.1-RELEASE-p3 GENERIC There were no relevant changes between -p3 and -p5, even more, there were no even possibly related changes. I suspect either you have some module with wrong KBI loaded, or your kernel was corrupted, or the issue is racy enough that it is harder to reproduce now. Perhaps try HEAD kernel ? Again, enable INVARIANTS and debugging symbols. > > Architecture: amd64 > Architecture Version: 2 > Dump Length: 1202487296 > Blocksize: 512 > Compression: none > Dumptime: Sun May 10 19:44:37 2020 > Hostname: > Magic: FreeBSD Kernel Dump > Version String: FreeBSD 12.1-RELEASE-p3 GENERIC > Panic String: page fault > Dump Parity: 3631849229 > Bounds: 2 > > May 10 19:43:33 kernel: pid 19891 (Discord), jid 0, uid 1001: exited on > signal 5 (core dumped) > May 10 19:43:35 kernel: pid 23929 (Discord), jid 0, uid 1001: exited on > signal 5 (core dumped) > May 10 19:45:17 syslogd: kernel boot file is /boot/kernel/kernel > May 10 19:45:17 kernel: > May 10 19:45:17 syslogd: last message repeated 1 times > May 10 19:45:17 kernel: Fatal trap 12: page fault while in kernel mode > May 10 19:45:17 kernel: cpuid = 3; apic id = 03 > May 10 19:45:17 kernel: fault virtual address = 0x18 > May 10 19:45:17 kernel: fault code = supervisor read data, page > not present > May 10 19:45:17 kernel: instruction pointer = 0x20:0xffffffff82f5b682 > May 10 19:45:17 kernel: stack pointer = 0x28:0xfffffe00691fd980 > May 10 19:45:17 kernel: frame pointer = 0x28:0xfffffe00691fd9e0 > May 10 19:45:17 kernel: code segment = base 0x0, limit 0xfffff, > type 0x1b > May 10 19:45:17 kernel: = DPL 0, pres 1, long 1, > def32 0, gran 1 > May 10 19:45:17 kernel: processor eflags = interrupt enabled, resume, > IOPL = 0 > May 10 19:45:17 kernel: current process = 17392 (fish) > May 10 19:45:17 kernel: trap number = 12 > May 10 19:45:17 kernel: panic: page fault > May 10 19:45:17 kernel: cpuid = 3 > May 10 19:45:17 kernel: time = 1589132677 > May 10 19:45:17 kernel: KDB: stack backtrace: > May 10 19:45:17 kernel: #0 0xffffffff80c1d2f7 at kdb_backtrace+0x67 > May 10 19:45:17 kernel: #1 0xffffffff80bd062d at vpanic+0x19d > May 10 19:45:17 kernel: #2 0xffffffff80bd0483 at panic+0x43 > May 10 19:45:17 kernel: #3 0xffffffff810a7dcc at trap_fatal+0x39c > May 10 19:45:17 kernel: #4 0xffffffff810a7e19 at trap_pfault+0x49 > May 10 19:45:17 kernel: #5 0xffffffff810a740f at trap+0x29f > May 10 19:45:17 kernel: #6 0xffffffff81081bdc at calltrap+0x8 > May 10 19:45:17 kernel: #7 0xffffffff82f503d1 at linux_thread_detach+0x21 > May 10 19:45:17 kernel: #8 0xffffffff80be5acf at thread_suspend_check+0x41f > May 10 19:45:17 kernel: #9 0xffffffff80c32ed9 at ast+0x3b9 > May 10 19:45:17 kernel: #10 0xffffffff810850e9 at doreti_ast+0x1f > May 10 19:45:17 kernel: Uptime: 2h56m24s > May 10 19:45:17 kernel: Dumping 1146 out of 8042 > MB:..2%..12%..21%..31%..41%..51%..62%..72%..81%..91%---<>--- > May 10 19:45:17 kernel: Copyright (c) 1992-2019 The FreeBSD Project. > May 10 19:45:17 kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, > 1991, 1992, 1993, 1994 > May 10 19:45:17 kernel: The Regents of the University of California. > All rights reserved. > May 10 19:45:17 kernel: FreeBSD is a registered trademark of The FreeBSD > Foundation. > May 10 19:45:17 kernel: FreeBSD 12.1-RELEASE-p3 GENERIC amd64 > May 10 19:45:17 kernel: FreeBSD clang version 8.0.1 (tags/RELEASE_801/final > 366581) (based on LLVM 8.0.1) > May 10 19:45:17 kernel: VT(vga): resolution 640x480 > May 10 19:45:17 kernel: CPU: Intel(R) Core(TM) i7-2670QM CPU @ 2.20GHz > (2195.07-MHz K8-class CPU) > May 10 19:45:17 kernel: Origin="GenuineIntel" Id=0x206a7 Family=0x6 > Model=0x2a Stepping=7 > May 10 19:45:17 kernel: Features=0xbfebfbff > May 10 19:45:17 kernel: Features2=0x1fbae3bf > May 10 19:45:17 kernel: AMD Features=0x28100800 > May 10 19:45:17 kernel: AMD Features2=0x1 > May 10 19:45:17 kernel: XSAVE Features=0x1 > May 10 19:45:17 kernel: VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID From owner-freebsd-hackers@freebsd.org Fri May 15 18:01:35 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id A5B492FC66A for ; Fri, 15 May 2020 18:01:35 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 49Nx7322Gwz4DQ2 for ; Fri, 15 May 2020 18:01:35 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: by mailman.nyi.freebsd.org (Postfix) id 45AA42FC668; Fri, 15 May 2020 18:01:35 +0000 (UTC) Delivered-To: hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 4562E2FC667; Fri, 15 May 2020 18:01:35 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 49Nx7163kTz4DPw; Fri, 15 May 2020 18:01:33 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 04FI1Oju022407 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 15 May 2020 14:01:27 -0400 Date: Fri, 15 May 2020 11:01:24 -0700 From: Benjamin Kaduk To: "Julian H. Stacey" Cc: "freebsd-arch@freebsd.org" , "freebsd-hackers@freebsd.org" , Kyle Evans , Poul-Henning Kamp , Alan Somers , Arne Steinkamm Subject: Re: [HEADSUP] Disallowing read() of a directory fd Message-ID: <20200515180124.GB27494@kduck.mit.edu> References: <202005151504.04FF423p040952@fire.js.berklix.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <202005151504.04FF423p040952@fire.js.berklix.net> User-Agent: Mutt/1.12.1 (2019-06-15) X-Rspamd-Queue-Id: 49Nx7163kTz4DPw X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of kaduk@mit.edu designates 18.9.28.11 as permitted sender) smtp.mailfrom=kaduk@mit.edu X-Spamd-Result: default: False [-5.42 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:18.9.28.0/24]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[mit.edu]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_MED(-0.20)[11.28.9.18.list.dnswl.org : 127.0.11.2]; RCPT_COUNT_SEVEN(0.00)[7]; IP_SCORE(-2.92)[ip: (-9.68), ipnet: 18.9.0.0/16(-4.80), asn: 3(-0.06), country: US(-0.05)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:3, ipnet:18.9.0.0/16, country:US]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 18:01:35 -0000 On Fri, May 15, 2020 at 05:04:02PM +0200, Julian H. Stacey wrote: > > kevans@ wasted FreeBSD time with threat of change at 2 days notice, I disagree with describing the proposal as a "threat of change", and am confident that the response thus far has met the "substantial objection" threshold needed to pause the intent to commit pending further discussion/revision. I'm not replying to the other points, that others have covered already. -Ben From owner-freebsd-hackers@freebsd.org Fri May 15 18:07:51 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 409B42FC973 for ; Fri, 15 May 2020 18:07:51 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 49NxGG65hvz4Dy0 for ; Fri, 15 May 2020 18:07:50 +0000 (UTC) (envelope-from jhs@berklix.com) Received: by mailman.nyi.freebsd.org (Postfix) id D14342FC971; Fri, 15 May 2020 18:07:50 +0000 (UTC) Delivered-To: hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D0F1E2FC970; Fri, 15 May 2020 18:07:50 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from slim.berklix.org (slim.berklix.org [94.185.90.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "slim.berklix.org", Issuer "slim.berklix.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 49NxGF2wZZz4Dxv; Fri, 15 May 2020 18:07:49 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from mart.js.berklix.net (p5DDB7209.dip0.t-ipconnect.de [93.219.114.9]) (authenticated bits=128) by slim.berklix.org (8.15.2/8.15.2) with ESMTPSA id 04FI7fEc066498 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 May 2020 20:07:45 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id 04FI7eBh099847; Fri, 15 May 2020 20:07:40 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.7/8.14.7) with ESMTP id 04FI7K8q045648; Fri, 15 May 2020 20:07:30 +0200 (CEST) (envelope-from jhs@berklix.com) Message-Id: <202005151807.04FI7K8q045648@fire.js.berklix.net> To: "Poul-Henning Kamp" cc: "freebsd-arch@freebsd.org" , "freebsd-hackers@freebsd.org" , Kyle Evans , Alan Somers , Arne Steinkamm Subject: Re: [HEADSUP] Disallowing read() of a directory fd From: "Julian H. Stacey" Organization: http://berklix.com/jhs http://stolenvotes.uk User-agent: EXMH on FreeBSD http://berklix.com/free/ X-From: http://www.berklix.org/~jhs/ In-reply-to: Your message "Fri, 15 May 2020 16:11:24 -0000." <44546.1589559084@critter.freebsd.dk> Date: Fri, 15 May 2020 20:07:20 +0200 X-Rspamd-Queue-Id: 49NxGF2wZZz4Dxv X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of jhs@berklix.com has no SPF policy when checking 94.185.90.68) smtp.mailfrom=jhs@berklix.com X-Spamd-Result: default: False [0.27 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.80)[-0.800,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[berklix.com]; AUTH_NA(1.00)[]; RCPT_COUNT_FIVE(0.00)[6]; HAS_ORG_HEADER(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.17)[0.168,0]; RCVD_IN_DNSWL_NONE(0.00)[68.90.185.94.list.dnswl.org : 127.0.10.0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:33824, ipnet:94.185.88.0/22, country:DE]; RCVD_TLS_LAST(0.00)[]; IP_SCORE(-0.00)[ip: (0.01), ipnet: 94.185.88.0/22(0.01), asn: 33824(-0.00), country: DE(-0.02)]; RECEIVED_SPAMHAUS_PBL(0.00)[9.114.219.93.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 18:07:51 -0000 "Poul-Henning Kamp" wrote: > -------- > In message <202005151504.04FF423p040952@fire.js.berklix.net>, "Julian H. Stacey > " writes: > > >No. Root is Root regardless if in a jail or not. > > No. Thanks, Accepting you mean: power of a root login within a jail is less. Yes I knew that, but I guess mine above was ambiguous, & more so without text restored below. I meant root the person, who has to login & fix various hosts, regardless if they are jails or not. It's already harder to work in jails; further limitation unwelcome. > > A root admin of > > a server in a jail needs full power without waiting days to contact > > other root human who owns the prison, without wasting human time > > of jail owner & prison owner formulating email request & considering > > & enabling requirement. > See also: https://papers.freebsd.org/2000/phk-jails/ Will do, thanks. Cheers -- Julian Stacey, Consultant Systems Engineer, BSD Linux http://berklix.com/jhs/ http://www.berklix.org/corona/#masks Tie 2 handkerchiefs or 1 pillow case. Jobs & economy hit by Corona to be hit again by Crash Brexit 31st Dec. 2020 From owner-freebsd-hackers@freebsd.org Fri May 15 19:49:34 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 1DB5F2FEC07 for ; Fri, 15 May 2020 19:49:34 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ultimatedns.net", Issuer "Let's Encrypt Authority X3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 49NzWd52fjz4MRv; Fri, 15 May 2020 19:49:33 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (localhost [IPv6:0:0:0:0:0:0:0:1]) by udns.ultimatedns.net (8.15.2/8.15.2) with ESMTPS id 04FJnobC057377 (version=TLSv1.2 cipher=DHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 15 May 2020 12:49:56 -0700 (PDT) (envelope-from bsd-lists@BSDforge.com) X-Mailer: Cypht MIME-Version: 1.0 Cc: FreeBSD Hackers In-Reply-To: From: Chris Reply-To: bsd-lists@BSDforge.com To: Ed Maste Subject: Re: [HEADSUP] Disallowing read() of a directory fd Date: Fri, 15 May 2020 12:49:56 -0700 Message-Id: <34b419c93394e7b933b3edcb43244a4d@udns.ultimatedns.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 49NzWd52fjz4MRv X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-1.48 / 15.00]; NEURAL_HAM_MEDIUM(-0.51)[-0.508,0]; NEURAL_HAM_LONG(-0.98)[-0.975,0]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US]; local_wl_ip(0.00)[24.113.41.81] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 19:49:34 -0000 On Fri, 15 May 2020 13:49:54 -0400 Ed Maste emaste@freebsd=2Eorg said > On Fri, 15 May 2020 at 13:14, Chris wrote: > > > > But given the potential > > gains for all this, are trivial at best=2E In a purely observational view=2E=2E=2E >=20 > Some benefits of this change have already been discussed: > 1=2E It would have prevented, or at least significantly blunted, the > security issue described in FreeBSD-SA-19:10=2Eufs=2E > 2=2E It avoids problems caused by application assumptions=2E Applications that fail in this regard, are poorly designed, and need to step up=2E It's not up to (Free)BSD to bend to their lazyness=2E >=20 > On the other hand, arguments for allowing reads of directories: > 1=2E It's always been that way=2E > 2=2E File system developers and experts may use the ability for certain > special or unusual actions=2E >=20 > Making the change with a sysctl to control still allows the special > case use, and I'm glad that Kyle spent the time on this change=2E I too conceded to this perhaps being a reasonable approach=2E So long as it wasn't read-only=2E In the end; given that there was a non perceivable amount of noise on this over the last 40 some yrs=2E It hardly seemed worth/any effort(s)=2E -- observationally speaking; not emotionally :-) --Chris From owner-freebsd-hackers@freebsd.org Fri May 15 20:01:04 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D267B2FF1D5 for ; Fri, 15 May 2020 20:01:04 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 49Nzmw1Hbmz4NSG for ; Fri, 15 May 2020 20:01:04 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: by mailman.nyi.freebsd.org (Postfix) id 29D5C2FF1CF; Fri, 15 May 2020 20:01:04 +0000 (UTC) Delivered-To: hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 296D62FF1CD; Fri, 15 May 2020 20:01:04 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 49Nzms6cBkz4NS2; Fri, 15 May 2020 20:01:01 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id ZgVsjkptQ62brZgVujvK3u; Fri, 15 May 2020 14:00:59 -0600 X-Authority-Analysis: v=2.3 cv=LKf9vKe9 c=1 sm=1 tr=0 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=xqWC_Br6kY4A:10 a=kj9zAlcOel0A:10 a=sTwFKg_x9MkA:10 a=Ikt0M2cxAAAA:8 a=6I5d2MoRAAAA:8 a=YxBL1-UpAAAA:8 a=EkcXrb_YAAAA:8 a=PX1mssMcXtx11Gsav7AA:9 a=CjuIK1q_8ugA:10 a=iYm7J9qDpiSF5xNCBZUT:22 a=IjZwj45LgO3ly-622nXo:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=LK5xJRSDVpKd5WXXoEvA:22 Received: from slippy.cwsent.com (slippy [IPv6:fc00:1:1:1::5b]) by spqr.komquats.com (Postfix) with ESMTPS id 2985E452; Fri, 15 May 2020 13:00:56 -0700 (PDT) Received: from slippy.cwsent.com (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id 04FK0tr6006519; Fri, 15 May 2020 13:00:55 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Received: from slippy (cy@localhost) by slippy.cwsent.com (8.15.2/8.15.2/Submit) with ESMTP id 04FK0tjk006516; Fri, 15 May 2020 13:00:55 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <202005152000.04FK0tjk006516@slippy.cwsent.com> X-Authentication-Warning: slippy.cwsent.com: cy owned process doing -bs X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7.1 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: "Julian H. Stacey" cc: Kyle Evans , "freebsd-arch@freebsd.org" , hackers@freebsd.org Subject: Re: [HEADSUP] Disallowing read() of a directory fd In-reply-to: <202005142017.04EKH0aA093503@fire.js.berklix.net> References: <202005142017.04EKH0aA093503@fire.js.berklix.net> Comments: In-reply-to "Julian H. Stacey" message dated "Thu, 14 May 2020 22:17:00 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 15 May 2020 13:00:55 -0700 X-CMAE-Envelope: MS4wfGZ28CIBinMWwKmXrdF2FyXcoe4/VZsiwnx1FFEs7C87HEfX03+qKg3AV+MWgRQRRvILkgNM8DGbJ53QimCl7sUx/XBqTvvVmH68HiOSOZTQ/yWE8Fk8 lhBGHwAzdWG5qu+9yMYGSepZh7ZU2ZAq3wd9nCrHpg7qQ4mRwQrOTHXt6dRhjoGTPUTbvPMibEfnBZkXc3sGPZLZQjrBEWZKLvmH6fusM0xzX0b5dYPjWe/5 /THMhxJZUBuzwqqLNsFSJ1BNiaKkJbI8twi0TiZGTzM= X-Rspamd-Queue-Id: 49Nzms6cBkz4NS2 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of cy.schubert@cschubert.com has no SPF policy when checking 64.59.134.9) smtp.mailfrom=cy.schubert@cschubert.com X-Spamd-Result: default: False [-4.24 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[9.134.59.64.rep.mailspike.net : 127.0.0.18]; TO_DN_SOME(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MV_CASE(0.50)[]; REPLYTO_EQ_FROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; IP_SCORE(-2.54)[ip: (-6.74), ipnet: 64.59.128.0/20(-3.30), asn: 6327(-2.58), country: CA(-0.09)]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RECEIVED_SPAMHAUS_PBL(0.00)[17.125.67.70.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11]; ASN(0.00)[asn:6327, ipnet:64.59.128.0/20, country:CA]; RCVD_TLS_LAST(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[9.134.59.64.list.dnswl.org : 127.0.5.1] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 20:01:04 -0000 In message <202005142017.04EKH0aA093503@fire.js.berklix.net>, "Julian H. Stacey " writes: > Kyle Evans wrote: > > Hi, > > > > This is a heads up, given that I'm completely flipping our historical > > behavior- I intend to commit this review in a couple days' time > > without substantial objection: https://reviews.freebsd.org/D24596 > > > > With this, FreeBSD 13 will not allow read() of a directory fd, which > > could have previously returned some data from the underlying > > filesystem in no particular standardized format. > > > > This is a still-standards-compliant switch from one > > implementation-defined behavior to another that's already been adopted > > in various other popular kernels, to include OpenBSD, MacOS, and > > Linux. > > > > Worth noting is that there's not really one largely-compelling reasons > > to switch this after so many years (unless you find yourself that > > irate when you accidentally `cat` a directory), but there are some > > benefits which are briefly discussed in the commentary around the > > review along with the history of the current behavior. > > > > This change also simplifies filesystem implementations to some extent. > > > > Thanks, > > > > Kyle Evans > > There is ZERO need for a spurious change at 2 days notice after 42+ years ! It's been 42 or more years since this bug was introduced. Let's just fix it now instead of agonizing over it. -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org The need of the many outweighs the greed of the few. From owner-freebsd-hackers@freebsd.org Fri May 15 20:25:45 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id CB2D62FFF6C for ; Fri, 15 May 2020 20:25:45 +0000 (UTC) (envelope-from arne@Steinkamm.COM) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 49P0KP226rz4QgZ for ; Fri, 15 May 2020 20:25:45 +0000 (UTC) (envelope-from arne@Steinkamm.COM) Received: by mailman.nyi.freebsd.org (Postfix) id 411322FFF69; Fri, 15 May 2020 20:25:45 +0000 (UTC) Delivered-To: hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 40C102FFF68; Fri, 15 May 2020 20:25:45 +0000 (UTC) (envelope-from arne@Steinkamm.COM) Received: from mail.steinkamm.com (mail.steinkamm.com [194.127.175.194]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "steinkamm.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49P0KN0Hq5z4QgV; Fri, 15 May 2020 20:25:43 +0000 (UTC) (envelope-from arne@Steinkamm.COM) Received: from trajan.stk.cx (trajan.stk.cx [10.8.8.110]) by basis.steinkamm.com (8.15.2/8.15.2) with ESMTPS id 04FKPSbm017556 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 15 May 2020 22:25:28 +0200 (CEST) (envelope-from arne@steinkamm.com) Received: from trajan.stk.cx (localhost [127.0.0.1]) by trajan.stk.cx (8.15.2/8.15.2) with ESMTPS id 04FKPSZG083040 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 15 May 2020 22:25:28 +0200 (CEST) (envelope-from arne@trajan.stk.cx) Received: (from arne@localhost) by trajan.stk.cx (8.15.2/8.15.2/Submit) id 04FKPQVj082575; Fri, 15 May 2020 22:25:26 +0200 (CEST) (envelope-from arne) Date: Fri, 15 May 2020 22:25:26 +0200 From: Arne Steinkamm To: Cy Schubert Cc: "Julian H. Stacey" , Kyle Evans , "freebsd-arch@freebsd.org" , hackers@freebsd.org Subject: Re: [HEADSUP] Disallowing read() of a directory fd Message-ID: <20200515202526.GZ82984@trajan.stk.cx> Reply-To: arne@Steinkamm.COM References: <202005142017.04EKH0aA093503@fire.js.berklix.net> <202005152000.04FK0tjk006516@slippy.cwsent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <202005152000.04FK0tjk006516@slippy.cwsent.com> User-Agent: Mutt@Trajan/1.12.1 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on basis.steinkamm.com X-Rspamd-Queue-Id: 49P0KN0Hq5z4QgV X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of arne@Steinkamm.COM has no SPF policy when checking 194.127.175.194) smtp.mailfrom=arne@Steinkamm.COM X-Spamd-Result: default: False [1.51 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; HAS_REPLYTO(0.00)[arne@Steinkamm.COM]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.51)[-0.511,0]; IP_SCORE(-0.00)[country: DE(-0.02)]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[Steinkamm.COM]; REPLYTO_DOM_EQ_FROM_DOM(0.00)[]; AUTH_NA(1.00)[]; RCPT_COUNT_FIVE(0.00)[5]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.82)[0.822,0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[freebsd-hackers@Steinkamm.COM,arne@Steinkamm.COM]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:34646, ipnet:194.127.175.0/24, country:DE]; FROM_NEQ_ENVFROM(0.00)[freebsd-hackers@Steinkamm.COM,arne@Steinkamm.COM]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 20:25:45 -0000 On Fri, May 15, 2020 at 01:00:55PM -0700, Cy Schubert wrote: > It's been 42 or more years since this bug was introduced. Let's just fix it > now instead of agonizing over it. I didn't want to add something as everything is said, but this sentence is a little bit to provocative. Everything is a file describes one of the defining features of Unix. Calling this defining feature of Unix a bug shows to me that the ideas behind Unix got lost in the FreeBSD universe too... .//. Arne -- Arne Steinkamm | Home: Mail: arnesteinkammcom From owner-freebsd-hackers@freebsd.org Fri May 15 21:08:42 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 9E6D72D9A39 for ; Fri, 15 May 2020 21:08:42 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 49P1Gy0xFfz4Scx for ; Fri, 15 May 2020 21:08:42 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: by mailman.nyi.freebsd.org (Postfix) id 201392D9A35; Fri, 15 May 2020 21:08:42 +0000 (UTC) Delivered-To: hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 1FC8B2D9A34; Fri, 15 May 2020 21:08:42 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-so.shaw.ca (smtp-out-so.shaw.ca [64.59.136.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 49P1Gw5Y3zz4Sct; Fri, 15 May 2020 21:08:40 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id ZhZKjwTUmYYpxZhZLjBeTm; Fri, 15 May 2020 15:08:38 -0600 X-Authority-Analysis: v=2.3 cv=OubUNx3t c=1 sm=1 tr=0 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=xqWC_Br6kY4A:10 a=kj9zAlcOel0A:10 a=sTwFKg_x9MkA:10 a=6I5d2MoRAAAA:8 a=YxBL1-UpAAAA:8 a=EkcXrb_YAAAA:8 a=eYNpW-z5zCPCEBFOaAsA:9 a=CjuIK1q_8ugA:10 a=IjZwj45LgO3ly-622nXo:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=LK5xJRSDVpKd5WXXoEvA:22 Received: from slippy.cwsent.com (slippy [IPv6:fc00:1:1:1::5b]) by spqr.komquats.com (Postfix) with ESMTPS id B5CD059F; Fri, 15 May 2020 14:08:33 -0700 (PDT) Received: from slippy.cwsent.com (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id 04FL8XgW007133; Fri, 15 May 2020 14:08:33 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Received: from slippy (cy@localhost) by slippy.cwsent.com (8.15.2/8.15.2/Submit) with ESMTP id 04FL8WeJ007130; Fri, 15 May 2020 14:08:32 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <202005152108.04FL8WeJ007130@slippy.cwsent.com> X-Authentication-Warning: slippy.cwsent.com: cy owned process doing -bs X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7.1 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Kyle Evans cc: Poul-Henning Kamp , Alan Somers , "Julian H. Stacey" , "freebsd-arch@freebsd.org" , "freebsd-hackers@freebsd.org" Subject: Re: [HEADSUP] Disallowing read() of a directory fd In-reply-to: References: <202005142017.04EKH0aA093503@fire.js.berklix.net> <33549.1589488226@critter.freebsd.dk> Comments: In-reply-to Kyle Evans message dated "Fri, 15 May 2020 00:10:35 -0500." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 15 May 2020 14:08:32 -0700 X-CMAE-Envelope: MS4wfMifuAH4ZttWaMWykk8z+rExp2qTh0SdQv6mZtQHLZXc03pAlJ8GbWIcYAIPeA5Kax9JvLIOoGsQKY0WBq1EMPtQtC3f8Pr+5HqVs/UNVB9yjAF6++Va GWcVHJ/GHFTjynhkRgI1H3Q5ZLg4VQWm/IC1uo5/y2VcTIFoCbffpqi7v+d7gM4oR+yf+fKUhmiyYdZ0w1CZ+a0XM3ErVFQ7VJ3v8me8QU9ryqkAYDj7omgW dpkJDt/41E+l9JeHn3yHcSWJxzSuHqdEyyUkdd4dAF4aEUuOH3YUEWhd/0K+NjMQU2IZN0qNoaLLKsa0DmKp9KaZCqKhfvArjmk4kEqzsOI= X-Rspamd-Queue-Id: 49P1Gw5Y3zz4Sct X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of cy.schubert@cschubert.com has no SPF policy when checking 64.59.136.137) smtp.mailfrom=cy.schubert@cschubert.com X-Spamd-Result: default: False [-4.18 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com]; RCPT_COUNT_FIVE(0.00)[6]; REPLYTO_EQ_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[17.125.67.70.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6327, ipnet:64.59.128.0/20, country:CA]; RCVD_TLS_LAST(0.00)[]; IP_SCORE(-2.48)[ip: (-6.44), ipnet: 64.59.128.0/20(-3.30), asn: 6327(-2.58), country: CA(-0.09)]; RCVD_IN_DNSWL_LOW(-0.10)[137.136.59.64.list.dnswl.org : 127.0.5.1] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 21:08:42 -0000 In message , Kyle Evans writes: > On Thu, May 14, 2020 at 3:30 PM Poul-Henning Kamp wrote: > > > > -------- > > In message com> > > , Alan Somers writes: > > > > >Really? When is that occasionally useful? I've never seen anything usefu > l > > >come out of reading a directory. > > > > Two things I have done over the years: > > > > Figure out which filenames prevent a enormous but sparse directory > > from being compacted. > > > > Figure out which control characters were in a filename. > > > > Can we explore the possibility of using fsdb(8) to fulfill these needs > in a way that you'd be comfortable with? I am thoroughly motivated and > willing to do what I can to find a good path forward. We could add a I'd like to see a good business case before a developer spends their valuable time to fulfill a some function few if any people might use. Those objecting to this should demonstrate how they currently use read()ing directories. Otherwise IMO it's a waste of your time. > sysctl and remove the functionality from other filesystems that aren't > necessarily providing useful information and likely haven't been > audited for similar disclosures to > https://www.freebsd.org/security/advisories/FreeBSD-SA-19:10.ufs.asc > that may be exacerbated by read(2) on a dirfd, but I'd like to see if > there's any compromise that we can make where the compromise on my > side is that I have to put in the effort to otherwise enable presented > valid use-cases in an agreeable manner. > > Is there anything that I, as a developer that knows very little about > UFS and even less when compared to someone such as yourself, can do to > facilitate making this as easy as possible with the tooling otherwise > available? Again, I fail to see the reason why. What purpose would read()ing a directory serve? > > Looking at fsdb(8) briefly on this UFS partition I just spun up, it > seems as a somewhat low-hanging fruit that we could (in some/many > cases) infer a disk device from a standard directory/file path and > prompt for confirmation based on that, opening up to the proper inode, > even, as an example (wording would differ, and apologies for the > formatting): > > root@shiva:/mnt# stat etc > 682 12928 drwxr-xr-x 2 root wheel 26456 512 "May 14 23:58:27 2020" > "May 14 23:58:27 2020" "May 14 23:58:27 2020" "May 14 23:58:27 2020" > 32768 8 0 etc > > root@shiva:/mnt# fsdb etc > etc is not a disk device, but is mounted from /dev/md1. Use /dev/md1? [yn] y > ** /dev/md1 (NO WRITE) > Editing file system `/dev/md1' > Last Mounted on /mnt > current inode: directory > I=12928 MODE=40755 SIZE=512 > BTIME=May 14 23:58:27 2020 [611088000 nsec] > MTIME=May 14 23:58:27 2020 [614391000 nsec] > CTIME=May 14 23:58:27 2020 [614391000 nsec] > ATIME=May 14 23:58:27 2020 [614391000 nsec] > OWNER=root GRP=wheel LINKCNT=2 FLAGS=0 BLKCNT=8 GEN=a15cce24 > > fsdb (inum: 12928)> ls > slot 0 off 0 ino 12928 reclen 12: directory, `.' > slot 1 off 12 ino 2 reclen 500: directory, `..' > > fsdb (inum: 12928)> A print in hex command possibly. Would make more sense than reading a directory in the raw. -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org The need of the many outweighs the greed of the few. From owner-freebsd-hackers@freebsd.org Fri May 15 21:22:53 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 396182DA155 for ; Fri, 15 May 2020 21:22:53 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 49P1bJ6LTvz4TYr for ; Fri, 15 May 2020 21:22:52 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: by mailman.nyi.freebsd.org (Postfix) id D97DE2DA152; Fri, 15 May 2020 21:22:52 +0000 (UTC) Delivered-To: hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D928F2DA151; Fri, 15 May 2020 21:22:52 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-so.shaw.ca (smtp-out-so.shaw.ca [64.59.136.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 49P1bH2b1Hz4TYq; Fri, 15 May 2020 21:22:50 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id Zhn5jwZ05YYpxZhn7jBhiM; Fri, 15 May 2020 15:22:49 -0600 X-Authority-Analysis: v=2.3 cv=OubUNx3t c=1 sm=1 tr=0 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=xqWC_Br6kY4A:10 a=kj9zAlcOel0A:10 a=sTwFKg_x9MkA:10 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=EkcXrb_YAAAA:8 a=YwyvHg-N9EvwjEekwyUA:9 a=CjuIK1q_8ugA:10 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 a=LK5xJRSDVpKd5WXXoEvA:22 Received: from slippy.cwsent.com (slippy [IPv6:fc00:1:1:1::5b]) by spqr.komquats.com (Postfix) with ESMTPS id 61630537; Fri, 15 May 2020 14:22:47 -0700 (PDT) Received: from slippy.cwsent.com (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id 04FLMluj007217; Fri, 15 May 2020 14:22:47 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Received: from slippy (cy@localhost) by slippy.cwsent.com (8.15.2/8.15.2/Submit) with ESMTP id 04FLMkd8007214; Fri, 15 May 2020 14:22:47 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <202005152122.04FLMkd8007214@slippy.cwsent.com> X-Authentication-Warning: slippy.cwsent.com: cy owned process doing -bs X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7.1 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: "Poul-Henning Kamp" cc: Kyle Evans , Alan Somers , "Julian H. Stacey" , "freebsd-arch@freebsd.org" , "freebsd-hackers@freebsd.org" Subject: Re: [HEADSUP] Disallowing read() of a directory fd In-reply-to: <35501.1589529102@critter.freebsd.dk> References: <202005142017.04EKH0aA093503@fire.js.berklix.net> <33549.1589488226@critter.freebsd.dk> <35501.1589529102@critter.freebsd.dk> Comments: In-reply-to "Poul-Henning Kamp" message dated "Fri, 15 May 2020 07:51:42 -0000." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 15 May 2020 14:22:46 -0700 X-CMAE-Envelope: MS4wfANA8adDSzJTRtipvrqWGMZHDRYx3BCsTco9NeKiJ3KEv/lhqw9bNC2nGGsGcAKNseIzPiwBJyL7ZKsLkQEPaweYDzz4hN/ivILh2Mc3xZtnVHGCZ6nI hNhfy+/jEJzrLBp+H5WygSXJFt3YJyMuC8M7byI1WUrLowynaPDKOfs0Px9U7yo9vETsaucCPh/3gFcrrBL0rrDbX8fbwJMxVprv1AlhHo1ysKJj6ad0awvE trlbbIjaRzo+mApJaGp0W21ANIG/A/FITZq7usA2IRMC0u5z4k/3eJDZ1weYWdivltAv/7srEsRRuwDdftF+DvbwtZH3DahpRDTccAxtgsE= X-Rspamd-Queue-Id: 49P1bH2b1Hz4TYq X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of cy.schubert@cschubert.com has no SPF policy when checking 64.59.136.138) smtp.mailfrom=cy.schubert@cschubert.com X-Spamd-Result: default: False [-4.23 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com]; RCPT_COUNT_FIVE(0.00)[6]; REPLYTO_EQ_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[138.136.59.64.rep.mailspike.net : 127.0.0.17]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[17.125.67.70.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11]; R_SPF_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; RCVD_IN_DNSWL_LOW(-0.10)[138.136.59.64.list.dnswl.org : 127.0.5.1]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6327, ipnet:64.59.128.0/20, country:CA]; RCVD_TLS_LAST(0.00)[]; IP_SCORE(-2.53)[ip: (-6.66), ipnet: 64.59.128.0/20(-3.30), asn: 6327(-2.58), country: CA(-0.09)]; FROM_EQ_ENVFROM(0.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 21:22:53 -0000 In message <35501.1589529102@critter.freebsd.dk>, "Poul-Henning Kamp" writes: > -------- > In message m> > , Kyle Evans writes: > >On Thu, May 14, 2020 at 3:30 PM Poul-Henning Kamp wrote > : > > >Can we explore the possibility of using fsdb(8) to fulfill these needs > >in a way that you'd be comfortable with? > > First, I am perfectly comfortable with fsdb(8), but in both the two > scenarios it was much less timeconsuming to do: > > strings < /some/directory | head > > Which immediately gives you the first filenames in the directory, > without waiting for ls(1) to read the entire directory, which in > this case was well north of 100MB. > > In the other case > > hexdump -C < /some/directory | grep part_of_suspect_filename > > gave me the answer faster than I could have started fsdb, it gave > me the answer in convenient hexadecimal, and besides it was not > a UFS filesystem. > > Second, one of the major reasons, probably about 3/4 of the total > reason I ended up in FreeBSD, was because of some utterly shit > experiences with commercial operating systems, where I had been in > a tight corner at 00-dark o'clock, and run straight into something > some idiot of at the vendor thought root should not be able to do > "for their own safety". > > This change falls right into that category: If root wants to hexdump > a directory, an entire bloody disk, or even if root wants to go > and do binary surgery on a mounted file system with a hex-editor, > root should be able to do that. > > She may have to `sysctl kern.warranty_voided=999` first, to disable > *under normal circumstances* reasonable and sensible protections. > > I'm perfectly fine with that: We do not want to make being root a > minefield, and I myself put the ability to munge mounted filesystems > under such a interlock in GEOM. > > But we should not make it *impossible* to do these things, and in > particular, we should not make them require a reboot, because ten > times out of nine, when you find yourself doing this kind of shit, > it is usually because you're pretty sure everything is lost if you > reboot. > > Summary: I'm perfectly fine with read(2) returning error on a > directory *under normal circumstances*, and I think it makes good > sense by protecting a lot of terminals from a lot of binary > garbage. > > But there is absolutely no reason to make it *impossible* for > a competent root to do what competent roots do. A kern.geom.debugflags-like thing might help but the complexity the code remains. Kyle's patch reduces complexity to a degree. A debugflags sysctl won't, it will add a little complexity. -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org The need of the many outweighs the greed of the few. From owner-freebsd-hackers@freebsd.org Fri May 15 21:24:39 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 342BA2DA544 for ; Fri, 15 May 2020 21:24:39 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 49P1dL6BTgz4Trt for ; Fri, 15 May 2020 21:24:38 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: by mailman.nyi.freebsd.org (Postfix) id D28DD2DA537; Fri, 15 May 2020 21:24:38 +0000 (UTC) Delivered-To: hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D23842DA536; Fri, 15 May 2020 21:24:38 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 49P1dK4rsBz4Trd; Fri, 15 May 2020 21:24:37 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id ZholjRFzcng7KZhonjeaji; Fri, 15 May 2020 15:24:35 -0600 X-Authority-Analysis: v=2.3 cv=ecemg4MH c=1 sm=1 tr=0 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=xqWC_Br6kY4A:10 a=kj9zAlcOel0A:10 a=sTwFKg_x9MkA:10 a=NRF7K_vUAAAA:8 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=EkcXrb_YAAAA:8 a=gs-f4NG6evmkO6fCgWAA:9 a=CjuIK1q_8ugA:10 a=-TUkS2ffhQBfG7ohTqvO:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 a=LK5xJRSDVpKd5WXXoEvA:22 Received: from slippy.cwsent.com (slippy [IPv6:fc00:1:1:1::5b]) by spqr.komquats.com (Postfix) with ESMTPS id 87F985BB; Fri, 15 May 2020 14:24:31 -0700 (PDT) Received: from slippy.cwsent.com (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id 04FLOVL6007256; Fri, 15 May 2020 14:24:31 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Received: from slippy (cy@localhost) by slippy.cwsent.com (8.15.2/8.15.2/Submit) with ESMTP id 04FLOUNq007253; Fri, 15 May 2020 14:24:31 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <202005152124.04FLOUNq007253@slippy.cwsent.com> X-Authentication-Warning: slippy.cwsent.com: cy owned process doing -bs X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7.1 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Warner Losh cc: "Julian H. Stacey" , "freebsd-arch@freebsd.org" , "freebsd-hackers@freebsd.org" , Kyle Evans , Poul-Henning Kamp , Alan Somers , Arne Steinkamm Subject: Re: [HEADSUP] Disallowing read() of a directory fd In-reply-to: References: <202005151504.04FF423p040952@fire.js.berklix.net> Comments: In-reply-to Warner Losh message dated "Fri, 15 May 2020 09:57:12 -0600." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 15 May 2020 14:24:30 -0700 X-CMAE-Envelope: MS4wfF/LejAwk4X4h+VQDh8s8Y7tD3xRWTO4z/Uh3AqNJMcNt0bNQHxOinQsokyrYz/npQ/hrjg67pmCMVMr5Y6+5g+nOlpTCii7Z8IV/mWNDds0jCWlaYei 0BAiFpRB3J6D0PTF64ws2D7cba+/ISku9/Xfk2yANKMPHnxfCZhvxYLW0K7MtmPehKRvv6fOYgR75HJ+6YhClBPKWpVCOzWkXbKzC8nowAFBTAoAJN67PrKV MT5+tj0NdU9j/fChbiHbBYzEVRk5o5g/3kiPBQ4+aUwrDsT3CM0Im9BTwXKpvLHBGDj7RTZlWN9w6WOQYEqPijSr93skOrhdBBK262b3RVkZqId8Js6cJSKx 5PRIzP0T1eCfNdObuGNmfNqH+mMFKR3F/dPPwBckmkZAmYB2oFI= X-Rspamd-Queue-Id: 49P1dK4rsBz4Trd X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of cy.schubert@cschubert.com has no SPF policy when checking 64.59.134.12) smtp.mailfrom=cy.schubert@cschubert.com X-Spamd-Result: default: False [-4.25 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com]; RWL_MAILSPIKE_GOOD(0.00)[12.134.59.64.rep.mailspike.net : 127.0.0.18]; REPLYTO_EQ_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[17.125.67.70.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_SEVEN(0.00)[8]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6327, ipnet:64.59.128.0/20, country:CA]; RCVD_TLS_LAST(0.00)[]; IP_SCORE(-2.55)[ip: (-6.77), ipnet: 64.59.128.0/20(-3.30), asn: 6327(-2.58), country: CA(-0.09)]; RCVD_IN_DNSWL_LOW(-0.10)[12.134.59.64.list.dnswl.org : 127.0.5.1] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 21:24:39 -0000 In message , Warner Losh writes: > On Fri, May 15, 2020 at 9:04 AM Julian H. Stacey wrote: > > > kevans@ wasted FreeBSD time with threat of change at 2 days notice, > > for an issue unchanged since 1972. The rush was immature. > > > > kevans@ should retract his threat of forced urgent change, or expect > > core@ be asked to remove his commit bit while FreeBSD considers > > _un-rushed_, allowing sufficient time for all to consider options, > > & to warn users in RELNOTES of any potential future change. > > > > Threats are not tolerated in this project. This hyperbolic response has > gone on long enough. Please stop and treat your fellow committers with > respect and a certain level of professionalism. He's done none of the > nefarious things you've said (I've known about this changes for days if not > weeks as he socialized it, for example). He doesn't deserve this level of > grief over a proposal. It's a request for comments, not a request for abuse > and nasty behaviour. > > This whole thread has gone toxic / hyperbolic over a non-issue. You should > have stopped reading directories in 1983 when readdir was introduced > because UFS broke ls, find, du, etc. At best, it's a nice debugging tool > some folks don't want to lose. At worst, it causes bugs for programs that > accidentally read directories (and maybe some, like grep, need some minor > changes). It's not worth this much bile and venom. +1 -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org The need of the many outweighs the greed of the few. From owner-freebsd-hackers@freebsd.org Fri May 15 22:00:01 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 1F09E2DB29A for ; Fri, 15 May 2020 22:00:01 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 49P2Q85zQqz4WSR for ; Fri, 15 May 2020 22:00:00 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mailman.nyi.freebsd.org (Postfix) id CD1422DB294; Fri, 15 May 2020 22:00:00 +0000 (UTC) Delivered-To: hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id CB9BE2DB293; Fri, 15 May 2020 22:00:00 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-oi1-f179.google.com (mail-oi1-f179.google.com [209.85.167.179]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) 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 49P2Q73RFVz4WSM; Fri, 15 May 2020 21:59:59 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-oi1-f179.google.com with SMTP id d191so3562317oib.12; Fri, 15 May 2020 14:59:59 -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=Sb8oJ7xDyF38Y28ZipIiwHUTLj2w6/8R0/6W1llCvug=; b=Iawj8VeeJRuwpPHyUTg5MsxsA75+YHboRuH6nX6GWofdBdA2p3BZg1ntCGxs+UNHwa JavJuLmugIXSm9KuTkLZDuLUq9I0qIhEdDR9BVimLE39l4qBB4VDAQDLK24LCwlYs2Ub TXkY6fxXOFbmgW/EP5lKDrUmNFfAxGC8DmNwcwcmgZzwFuY62eA7u534b4lgV5XFmHuQ 97uB9Iv0paGmi0AGUUuUDhw8jbgC0pkRO9A84BUWByUxBU13ZD3Ne8HLYghbNCCDD7YI +V7RPBcBt+zrfK0pQQ6jcoRUX6tusAwoNkdEz/Gy5eiK6gqx5ZL8UwzDq52yFAlzSsI5 GLMw== X-Gm-Message-State: AOAM532nUdQX++oexXJCvTXIszfVVRhLd2lCrgr3rz6KIcRQZRSPR7U8 ntEWUAb+OPVlLQFHCNot5GGHa1/AgzWnZlwBqMQ7OKvD X-Google-Smtp-Source: ABdhPJzuNX5kn5vuPZ7DRdrkesxKZILmrAnp+nTKIx5QciZPJ5VsYnXrLl12H7RpPwumWmikDOoMZ6FQnns/jbtDu6w= X-Received: by 2002:aca:bf09:: with SMTP id p9mr3367994oif.55.1589579998133; Fri, 15 May 2020 14:59:58 -0700 (PDT) MIME-Version: 1.0 References: <202005142017.04EKH0aA093503@fire.js.berklix.net> <33549.1589488226@critter.freebsd.dk> <202005152108.04FL8WeJ007130@slippy.cwsent.com> In-Reply-To: <202005152108.04FL8WeJ007130@slippy.cwsent.com> From: Alan Somers Date: Fri, 15 May 2020 15:59:46 -0600 Message-ID: Subject: Re: [HEADSUP] Disallowing read() of a directory fd To: Cy Schubert Cc: Kyle Evans , Poul-Henning Kamp , "Julian H. Stacey" , "freebsd-arch@freebsd.org" , "freebsd-hackers@freebsd.org" X-Rspamd-Queue-Id: 49P2Q73RFVz4WSM X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.167.179 as permitted sender) smtp.mailfrom=asomers@gmail.com X-Spamd-Result: default: False [-2.20 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.991,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; NEURAL_HAM_LONG(-1.00)[-0.997,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; MIME_TRACE(0.00)[0:+,1:+,2:~]; DMARC_NA(0.00)[freebsd.org]; RCPT_COUNT_FIVE(0.00)[6]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[179.167.85.209.list.dnswl.org : 127.0.5.0]; IP_SCORE(-0.21)[ip: (-0.21), ipnet: 209.85.128.0/17(-0.39), asn: 15169(-0.42), country: US(-0.05)]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[179.167.85.209.rep.mailspike.net : 127.0.0.17]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 22:00:01 -0000 On Fri, May 15, 2020 at 3:08 PM Cy Schubert wrote: > In message > om> > , Kyle Evans writes: > > On Thu, May 14, 2020 at 3:30 PM Poul-Henning Kamp > wrote: > > > > > > -------- > > > In message > > com> > > > , Alan Somers writes: > > > > > > >Really? When is that occasionally useful? I've never seen anything > usefu > > l > > > >come out of reading a directory. > > > > > > Two things I have done over the years: > > > > > > Figure out which filenames prevent a enormous but sparse directory > > > from being compacted. > > > > > > Figure out which control characters were in a filename. > > > > > > > Can we explore the possibility of using fsdb(8) to fulfill these needs > > in a way that you'd be comfortable with? I am thoroughly motivated and > > willing to do what I can to find a good path forward. We could add a > > I'd like to see a good business case before a developer spends their > valuable time to fulfill a some function few if any people might use. > Those > objecting to this should demonstrate how they currently use read()ing > directories. Otherwise IMO it's a waste of your time. > +1. The suggested use cases are marginal, and would be better served by fsdb. Disallowing reads on directories makes sense. Kyle ought to unconditionally disable until a real need is proven. -Alan From owner-freebsd-hackers@freebsd.org Fri May 15 22:09:29 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 177962DB7BE; Fri, 15 May 2020 22:09:29 +0000 (UTC) (envelope-from joerg@bec.de) Received: from relay6-d.mail.gandi.net (relay6-d.mail.gandi.net [217.70.183.198]) (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 49P2d35yXcz4X4f; Fri, 15 May 2020 22:09:27 +0000 (UTC) (envelope-from joerg@bec.de) X-Originating-IP: 87.153.206.8 Received: from bec.de (p5799ce08.dip0.t-ipconnect.de [87.153.206.8]) (Authenticated sender: joerg@bec.de) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id F2D29C0005; Fri, 15 May 2020 22:09:24 +0000 (UTC) Date: Sat, 16 May 2020 00:09:23 +0200 From: Joerg Sonnenberger To: freebsd-hackers@freebsd.org, hackers@freebsd.org Subject: Re: [HEADSUP] Disallowing read() of a directory fd Message-ID: <20200515220923.GA36597@bec.de> Mail-Followup-To: freebsd-hackers@freebsd.org, hackers@freebsd.org References: <202005142017.04EKH0aA093503@fire.js.berklix.net> <202005152000.04FK0tjk006516@slippy.cwsent.com> <20200515202526.GZ82984@trajan.stk.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200515202526.GZ82984@trajan.stk.cx> User-Agent: Mutt/1.11.3 (2019-02-01) X-Rspamd-Queue-Id: 49P2d35yXcz4X4f X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of joerg@bec.de has no SPF policy when checking 217.70.183.198) smtp.mailfrom=joerg@bec.de X-Spamd-Result: default: False [-2.39 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; HAS_XOIP(0.00)[]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_NEUTRAL(0.00)[198.183.70.217.rep.mailspike.net : 127.0.0.13]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.999,0]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[bec.de]; AUTH_NA(1.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[8.206.153.87.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10]; IP_SCORE(-1.19)[ip: (-3.07), ipnet: 217.70.176.0/20(-1.61), asn: 29169(-1.29), country: FR(-0.00)]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_MEDIUM(-1.00)[-0.997,0]; R_SPF_NA(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[198.183.70.217.list.dnswl.org : 127.0.5.1]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:29169, ipnet:217.70.176.0/20, country:FR]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 22:09:29 -0000 On Fri, May 15, 2020 at 10:25:26PM +0200, Arne Steinkamm wrote: > On Fri, May 15, 2020 at 01:00:55PM -0700, Cy Schubert wrote: > > It's been 42 or more years since this bug was introduced. Let's just fix it > > now instead of agonizing over it. > > I didn't want to add something as everything is said, > but this sentence is a little bit to provocative. > > Everything is a file describes one of the defining features of Unix. > > Calling this defining feature of Unix a bug shows to me that the ideas > behind Unix got lost in the FreeBSD universe too... Using linear storage for a directory is an implementation detail of the implementation. It's not a defining feature. "Reading" from a directory doesn't make sense for many other organisational forms. So, are you now arguing that leaky abstractions are a defining feature of Unix? Joerg From owner-freebsd-hackers@freebsd.org Fri May 15 22:47:32 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id A96AD2DC503; Fri, 15 May 2020 22:47:32 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49P3Sz52N8z4YsB; Fri, 15 May 2020 22:47:31 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: by sdaoden.eu (Postfix, from userid 1000) id B1C0716054; Sat, 16 May 2020 00:47:24 +0200 (CEST) Date: Sat, 16 May 2020 00:47:24 +0200 From: Steffen Nurpmeso To: freebsd-hackers@freebsd.org, hackers@freebsd.org Subject: Re: [HEADSUP] Disallowing read() of a directory fd Message-ID: <20200515224724.WFACq%steffen@sdaoden.eu> In-Reply-To: <20200515220923.GA36597@bec.de> References: <202005142017.04EKH0aA093503@fire.js.berklix.net> <202005152000.04FK0tjk006516@slippy.cwsent.com> <20200515202526.GZ82984@trajan.stk.cx> <20200515220923.GA36597@bec.de> Mail-Followup-To: freebsd-hackers@freebsd.org, hackers@freebsd.org User-Agent: s-nail v14.9.19-42-g6235a28f OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs. X-Rspamd-Queue-Id: 49P3Sz52N8z4YsB X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of steffen@sdaoden.eu designates 217.144.132.164 as permitted sender) smtp.mailfrom=steffen@sdaoden.eu X-Spamd-Result: default: False [0.57 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.74)[-0.744,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+a]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[sdaoden.eu]; RCPT_COUNT_TWO(0.00)[2]; MID_CONTAINS_FROM(1.00)[]; NEURAL_SPAM_LONG(0.34)[0.338,0]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15987, ipnet:217.144.128.0/20, country:DE]; IP_SCORE(0.28)[asn: 15987(1.41), country: DE(-0.02)] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 22:47:32 -0000 Joerg Sonnenberger wrote in <20200515220923.GA36597@bec.de>: |On Fri, May 15, 2020 at 10:25:26PM +0200, Arne Steinkamm wrote: |> On Fri, May 15, 2020 at 01:00:55PM -0700, Cy Schubert wrote: |>> It's been 42 or more years since this bug was introduced. Let's \ |>> just fix it |>> now instead of agonizing over it. |> |> I didn't want to add something as everything is said, |> but this sentence is a little bit to provocative. |> |> Everything is a file describes one of the defining features of Unix. |> |> Calling this defining feature of Unix a bug shows to me that the ideas |> behind Unix got lost in the FreeBSD universe too... | |Using linear storage for a directory is an implementation detail of the |implementation. It's not a defining feature. "Reading" from a directory |doesn't make sense for many other organisational forms. So, are you now |arguing that leaky abstractions are a defining feature of Unix? In an ideal Unix world read(2)ing from a directory fd would do the job that getdents(2) / getdirentries(2) never moved to a standard, leaving us with that terrible readdir(3) stuff. imho. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From owner-freebsd-hackers@freebsd.org Fri May 15 23:06:54 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 041182DCE47 for ; Fri, 15 May 2020 23:06:54 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 49P3vK4Zwrz4bBD for ; Fri, 15 May 2020 23:06:53 +0000 (UTC) (envelope-from jhs@berklix.com) Received: by mailman.nyi.freebsd.org (Postfix) id 9B7642DCE41; Fri, 15 May 2020 23:06:53 +0000 (UTC) Delivered-To: hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 9B2732DCE40; Fri, 15 May 2020 23:06:53 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from slim.berklix.org (slim.berklix.org [94.185.90.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "slim.berklix.org", Issuer "slim.berklix.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 49P3v90485z4bB9; Fri, 15 May 2020 23:06:44 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from mart.js.berklix.net (p2E52C9E4.dip0.t-ipconnect.de [46.82.201.228]) (authenticated bits=128) by slim.berklix.org (8.15.2/8.15.2) with ESMTPSA id 04FN6c2Q069463 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 16 May 2020 01:06:43 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id 04FN6cHl001735; Sat, 16 May 2020 01:06:38 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.7/8.14.7) with ESMTP id 04FN6Irf049862; Sat, 16 May 2020 01:06:28 +0200 (CEST) (envelope-from jhs@berklix.com) Message-Id: <202005152306.04FN6Irf049862@fire.js.berklix.net> To: "freebsd-arch@freebsd.org" , "freebsd-hackers@freebsd.org" cc: Kyle Evans , Poul-Henning Kamp , Alan Somers , Arne Steinkamm Subject: Re: [HEADSUP] Disallowing read() of a directory fd From: "Julian H. Stacey" Organization: http://berklix.com/jhs http://stolenvotes.uk User-agent: EXMH on FreeBSD http://berklix.com/free/ X-From: http://www.berklix.org/~jhs/ In-reply-to: Your message "Fri, 15 May 2020 09:00:56 -0700." Date: Sat, 16 May 2020 01:06:18 +0200 X-Rspamd-Queue-Id: 49P3v90485z4bB9 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of jhs@berklix.com has no SPF policy when checking 94.185.90.68) smtp.mailfrom=jhs@berklix.com X-Spamd-Result: default: False [0.31 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.77)[-0.770,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[berklix.com]; AUTH_NA(1.00)[]; RCPT_COUNT_FIVE(0.00)[6]; HAS_ORG_HEADER(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.18)[0.180,0]; RCVD_IN_DNSWL_NONE(0.00)[68.90.185.94.list.dnswl.org : 127.0.10.0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:33824, ipnet:94.185.88.0/22, country:DE]; RCVD_TLS_LAST(0.00)[]; IP_SCORE(-0.00)[ip: (0.01), ipnet: 94.185.88.0/22(0.01), asn: 33824(-0.00), country: DE(-0.02)]; RECEIVED_SPAMHAUS_PBL(0.00)[228.201.82.46.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 23:06:54 -0000 > From: John Baldwin > I've watched many threads involving you over the past several years, Flame bait declined. > From: Warner Losh > It's not worth this much bile and venom. Friction is risked when ever code is rammed too fast. Seen it before. Self discipline with delay can avoid friction. Wider review & generous time scales can reduce friction. Enforced commit review policy could avoid friction. It's best to criticise ideas, not people. Cheers -- Julian Stacey, Consultant Systems Engineer, BSD Linux http://berklix.com/jhs/ http://www.berklix.org/corona/#masks Tie 2 handkerchiefs or 1 pillow case. Jobs & economy hit by Corona to be hit again by Crash Brexit 31st Dec. 2020 From owner-freebsd-hackers@freebsd.org Fri May 15 23:07:15 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 3B2C62DCED7; Fri, 15 May 2020 23:07:15 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-oi1-f194.google.com (mail-oi1-f194.google.com [209.85.167.194]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) 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 49P3vk3BBGz4bKj; Fri, 15 May 2020 23:07:14 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-oi1-f194.google.com with SMTP id i13so3728413oie.9; Fri, 15 May 2020 16:07:14 -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; bh=xizZhQcCy/cQPMFAbXjsn5zOHk6MEbE9CfxW+SKvLpA=; b=CV1SgB2vR/2kFwhqcNVWrU3gibwTqd3ie5hykA1Pmz7+x2K7QPwpioMbJ4v69/t8g6 PboyN16OX9gDuD3WikXIvHSQcmdy9m+zMCHuJTHMUkRkW4scpozjU9ss/CsDjCFwozYe IVMHCqUJsRQISCwKk037PQVP97OMyEPmauhtf/13laA2syGfIfWCQS+iOuL636+iK1bx NzD2gTvurLH6uDlkLNSwJ8/3T6wl/KB1x3F9RUOD4MaGRujzB2d5B33oAXT2IRsPySXL qNJr0BBOC3kxwUdoQU6zCeRlMKz10rgAqkjnOiH23wSjpJHwn+WKPJ9EhFX5kJwvE6Wk X7Hw== X-Gm-Message-State: AOAM530cob/lBEu+EXIp2AC+Zs9mIGYzGyb/0NW0oYMMacV1E9r81Kg0 PvGbxqNyXFRrbf0SBePnuc8NlVi87FqQ3KkiRxrLVR1g X-Google-Smtp-Source: ABdhPJx6Boxcv62D98NplgxB2o/b2yMaKxaOzPQOWSHZr7+6uHjiLN6xZ4hYKTQ/aMFUv/cwDGitvCba/oae6DKyHfQ= X-Received: by 2002:aca:4f4b:: with SMTP id d72mr3774227oib.73.1589584032851; Fri, 15 May 2020 16:07:12 -0700 (PDT) MIME-Version: 1.0 References: <202005142017.04EKH0aA093503@fire.js.berklix.net> <202005152000.04FK0tjk006516@slippy.cwsent.com> <20200515202526.GZ82984@trajan.stk.cx> <20200515220923.GA36597@bec.de> <20200515224724.WFACq%steffen@sdaoden.eu> In-Reply-To: <20200515224724.WFACq%steffen@sdaoden.eu> From: Alan Somers Date: Fri, 15 May 2020 17:07:01 -0600 Message-ID: Subject: Re: [HEADSUP] Disallowing read() of a directory fd To: "freebsd-hackers@freebsd.org" , "freebsd-hackers@freebsd.org" X-Rspamd-Queue-Id: 49P3vk3BBGz4bKj X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.167.194 as permitted sender) smtp.mailfrom=asomers@gmail.com X-Spamd-Result: default: False [-2.16 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_LONG(-1.00)[-0.997,0]; IP_SCORE(-0.17)[ip: (0.00), ipnet: 209.85.128.0/17(-0.39), asn: 15169(-0.42), country: US(-0.05)]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[194.167.85.209.list.dnswl.org : 127.0.5.0]; NEURAL_HAM_MEDIUM(-0.99)[-0.989,0]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[194.167.85.209.rep.mailspike.net : 127.0.0.17]; MIME_TRACE(0.00)[0:+,1:+,2:~]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 23:07:15 -0000 On Fri, May 15, 2020 at 4:47 PM Steffen Nurpmeso wrote: > Joerg Sonnenberger wrote in > <20200515220923.GA36597@bec.de>: > |On Fri, May 15, 2020 at 10:25:26PM +0200, Arne Steinkamm wrote: > |> On Fri, May 15, 2020 at 01:00:55PM -0700, Cy Schubert wrote: > |>> It's been 42 or more years since this bug was introduced. Let's \ > |>> just fix it > |>> now instead of agonizing over it. > |> > |> I didn't want to add something as everything is said, > |> but this sentence is a little bit to provocative. > |> > |> Everything is a file describes one of the defining features of Unix. > |> > |> Calling this defining feature of Unix a bug shows to me that the ideas > |> behind Unix got lost in the FreeBSD universe too... > | > |Using linear storage for a directory is an implementation detail of the > |implementation. It's not a defining feature. "Reading" from a directory > |doesn't make sense for many other organisational forms. So, are you now > |arguing that leaky abstractions are a defining feature of Unix? > > In an ideal Unix world read(2)ing from a directory fd would do the > job that getdents(2) / getdirentries(2) never moved to a standard, > leaving us with that terrible readdir(3) stuff. imho. > It's not a matter of philosophy. A directory simply can't be mapped to a flat file with good performance. Directories, for instance, must support random insertion and deletion. Old fashioned file systems cope by appending new directories to the end, but that necessitates linear search. By storing directories as hash tables instead of flat files, modern file systems like ZFS achieve good insertion, deletion, and search. So what if you can't list the directory's contents with read(2)? read(2) has poor semantics anyway. readdir(3) is much better (though yes it has problems with reentrancy and with NAME_MAX). -Alan From owner-freebsd-hackers@freebsd.org Fri May 15 23:09:33 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 949EC2DD115; Fri, 15 May 2020 23:09:33 +0000 (UTC) (envelope-from joerg@bec.de) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) (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 49P3yN40Gkz4bWr; Fri, 15 May 2020 23:09:32 +0000 (UTC) (envelope-from joerg@bec.de) X-Originating-IP: 87.153.206.8 Received: from bec.de (p5799CE08.dip0.t-ipconnect.de [87.153.206.8]) (Authenticated sender: joerg@bec.de) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 16009E0004; Fri, 15 May 2020 23:09:29 +0000 (UTC) Date: Sat, 16 May 2020 01:09:28 +0200 From: Joerg Sonnenberger To: freebsd-hackers@freebsd.org, hackers@freebsd.org Subject: Re: [HEADSUP] Disallowing read() of a directory fd Message-ID: <20200515230928.GA9126@bec.de> Mail-Followup-To: freebsd-hackers@freebsd.org, hackers@freebsd.org References: <202005142017.04EKH0aA093503@fire.js.berklix.net> <202005152000.04FK0tjk006516@slippy.cwsent.com> <20200515202526.GZ82984@trajan.stk.cx> <20200515220923.GA36597@bec.de> <20200515224724.WFACq%steffen@sdaoden.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200515224724.WFACq%steffen@sdaoden.eu> User-Agent: Mutt/1.11.3 (2019-02-01) X-Rspamd-Queue-Id: 49P3yN40Gkz4bWr X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of joerg@bec.de has no SPF policy when checking 217.70.183.196) smtp.mailfrom=joerg@bec.de X-Spamd-Result: default: False [-2.78 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; HAS_XOIP(0.00)[]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[196.183.70.217.rep.mailspike.net : 127.0.0.18]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.999,0]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[bec.de]; AUTH_NA(1.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[8.206.153.87.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10]; IP_SCORE(-1.58)[ip: (-5.01), ipnet: 217.70.176.0/20(-1.61), asn: 29169(-1.29), country: FR(-0.00)]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_MEDIUM(-1.00)[-0.998,0]; R_SPF_NA(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[196.183.70.217.list.dnswl.org : 127.0.5.1]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:29169, ipnet:217.70.176.0/20, country:FR]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 23:09:33 -0000 On Sat, May 16, 2020 at 12:47:24AM +0200, Steffen Nurpmeso wrote: > Joerg Sonnenberger wrote in > <20200515220923.GA36597@bec.de>: > |On Fri, May 15, 2020 at 10:25:26PM +0200, Arne Steinkamm wrote: > |> On Fri, May 15, 2020 at 01:00:55PM -0700, Cy Schubert wrote: > |>> It's been 42 or more years since this bug was introduced. Let's \ > |>> just fix it > |>> now instead of agonizing over it. > |> > |> I didn't want to add something as everything is said, > |> but this sentence is a little bit to provocative. > |> > |> Everything is a file describes one of the defining features of Unix. > |> > |> Calling this defining feature of Unix a bug shows to me that the ideas > |> behind Unix got lost in the FreeBSD universe too... > | > |Using linear storage for a directory is an implementation detail of the > |implementation. It's not a defining feature. "Reading" from a directory > |doesn't make sense for many other organisational forms. So, are you now > |arguing that leaky abstractions are a defining feature of Unix? > > In an ideal Unix world read(2)ing from a directory fd would do the > job that getdents(2) / getdirentries(2) never moved to a standard, > leaving us with that terrible readdir(3) stuff. imho. That still doesn't work well with non-linear representations of directories. readdir has issues, but plain read is even worse. Joerg From owner-freebsd-hackers@freebsd.org Sat May 16 03:29:46 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 89BD22E2913 for ; Sat, 16 May 2020 03:29:46 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ultimatedns.net", Issuer "Let's Encrypt Authority X3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 49P9kd59v3z3LGJ; Sat, 16 May 2020 03:29:45 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (localhost [IPv6:0:0:0:0:0:0:0:1]) by udns.ultimatedns.net (8.15.2/8.15.2) with ESMTPS id 04G3U272000826 (version=TLSv1.2 cipher=DHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 15 May 2020 20:30:09 -0700 (PDT) (envelope-from bsd-lists@BSDforge.com) X-Mailer: Cypht MIME-Version: 1.0 Cc: Ed Maste , In-Reply-To: <20200515231150.GB516@lonesome.com> From: Chris Reply-To: bsd-lists@BSDforge.com To: Mark Linimon Subject: Re: [HEADSUP] Disallowing read() of a directory fd Date: Fri, 15 May 2020 20:30:08 -0700 Message-Id: <2ea8236f935a4c786a0f4f06ca1d3ea3@udns.ultimatedns.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 49P9kd59v3z3LGJ X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-1.58 / 15.00]; NEURAL_HAM_MEDIUM(-0.60)[-0.598,0]; NEURAL_HAM_LONG(-0.98)[-0.978,0]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US]; local_wl_ip(0.00)[24.113.41.81] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 May 2020 03:29:46 -0000 On Fri, 15 May 2020 23:11:50 +0000 Mark Linimon linimon@lonesome=2Ecom said > On Fri, May 15, 2020 at 12:49:56PM -0700, Chris wrote: > > Applications that fail in this regard, are poorly designed, and > > need to step up=2E >=20 > freshports=2Eorg currently shows: >=20 > 39288 ports > 94 deprecated > 5 forbidden >=20 > If you want to fix every poorly-designed application in that swamp, > please feel free *=2E >=20 > Oh yeah, bugzilla says: >=20 > 2269 ports PRs >=20 > So, there's plenty to do=2E Indeed there is=2E But at last count, I was at 162 ports=2E So I think I'm already pretty close to my limit=2E :-) >=20 > mcl >=20 > * there are days where my remark would be "that includes most of them" --Chris From owner-freebsd-hackers@freebsd.org Sat May 16 15:18:29 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 35F522F4CEC; Sat, 16 May 2020 15:18:29 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from slim.berklix.org (slim.berklix.org [94.185.90.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "slim.berklix.org", Issuer "slim.berklix.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 49PTSN26wTz4c9Q; Sat, 16 May 2020 15:18:27 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from mart.js.berklix.net (p2E52C9E4.dip0.t-ipconnect.de [46.82.201.228]) (authenticated bits=128) by slim.berklix.org (8.15.2/8.15.2) with ESMTPSA id 04GFIKf2080724 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 16 May 2020 17:18:24 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id 04GFIK98007397; Sat, 16 May 2020 17:18:20 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.7/8.14.7) with ESMTP id 04GFIA0a099390; Sat, 16 May 2020 17:18:20 +0200 (CEST) (envelope-from jhs@berklix.com) Message-Id: <202005161518.04GFIA0a099390@fire.js.berklix.net> To: freebsd-arch@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: [HEADSUP] Disallowing read() of a directory fd From: "Julian H. Stacey" Organization: http://berklix.com/jhs http://stolenvotes.uk User-agent: EXMH on FreeBSD http://berklix.com/free/ X-From: http://www.berklix.org/~jhs/ In-reply-to: Your message "Fri, 15 May 2020 20:30:08 -0700." <2ea8236f935a4c786a0f4f06ca1d3ea3@udns.ultimatedns.net> Date: Sat, 16 May 2020 17:18:10 +0200 X-Rspamd-Queue-Id: 49PTSN26wTz4c9Q X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of jhs@berklix.com has no SPF policy when checking 94.185.90.68) smtp.mailfrom=jhs@berklix.com X-Spamd-Result: default: False [-0.12 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-0.81)[-0.815,0]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.20)[-0.200,0]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[berklix.com]; AUTH_NA(1.00)[]; HAS_ORG_HEADER(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; IP_SCORE(-0.00)[ip: (0.01), ipnet: 94.185.88.0/22(0.01), asn: 33824(-0.00), country: DE(-0.02)]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[68.90.185.94.list.dnswl.org : 127.0.10.0]; R_SPF_NA(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[228.201.82.46.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:33824, ipnet:94.185.88.0/22, country:DE]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 May 2020 15:18:29 -0000 Another use of "cat ." is to see names of transient files a tool creates, & normaly deletes, if not aborting, so one can find same name junk elsewhere, & search for tool causing junk, & ensure other data files avoid using names that would be zapped. While blocking "cat ." might be worked round if not in a jail, & or if using fsdb & sysctl etc, it would add to a more BSD specific environment, where standard portable Unix skills was insufficient, & more time needed to search & learn BSD extras. Every obstacle costs employers time = money. Cheers -- Julian Stacey, Consultant Systems Engineer, BSD Linux http://berklix.com/jhs/ http://www.berklix.org/corona/#masks Tie 2 handkerchiefs or 1 pillow case. Jobs & economy hit by Corona to be hit again by Crash Brexit 31st Dec. 2020 From owner-freebsd-hackers@freebsd.org Sat May 16 16:26:23 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 5940F2F66F5; Sat, 16 May 2020 16:26:23 +0000 (UTC) (envelope-from kevans@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) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49PVyl1dx2z3CrH; Sat, 16 May 2020 16:26:23 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-qv1-f52.google.com (mail-qv1-f52.google.com [209.85.219.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 2680C76B6; Sat, 16 May 2020 16:26:23 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qv1-f52.google.com with SMTP id g20so2644450qvb.9; Sat, 16 May 2020 09:26:23 -0700 (PDT) X-Gm-Message-State: AOAM531HrVnIwsiDY/xlC3WQk/DcdgGy2okwf7HpGJHuHkKl9kq9f2cV 4pl1B6r9aTFpWPoB9W+RgFuMhtDkCh96N/6opX4= X-Google-Smtp-Source: ABdhPJwr5nlj8YBBNBIITL7PfBdsTPYlMQnUCoVbA9fmFgt2VNocPcw4h8exB28ETDru9uJPaYj9/S6xUxjfZoTr1GA= X-Received: by 2002:a0c:f054:: with SMTP id b20mr8334283qvl.112.1589646382677; Sat, 16 May 2020 09:26:22 -0700 (PDT) MIME-Version: 1.0 References: <2ea8236f935a4c786a0f4f06ca1d3ea3@udns.ultimatedns.net> <202005161518.04GFIA0a099390@fire.js.berklix.net> In-Reply-To: <202005161518.04GFIA0a099390@fire.js.berklix.net> From: Kyle Evans Date: Sat, 16 May 2020 11:26:11 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [HEADSUP] Disallowing read() of a directory fd To: "Julian H. Stacey" Cc: "freebsd-arch@freebsd.org" , "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 May 2020 16:26:23 -0000 On Sat, May 16, 2020 at 10:18 AM Julian H. Stacey wrote: > > Another use of "cat ." is to see names of transient files a tool > creates, & normaly deletes, if not aborting, so one can find same > name junk elsewhere, & search for tool causing junk, > & ensure other data files avoid using names that would be zapped. > > While blocking "cat ." might be worked round if not in a jail, & > or if using fsdb & sysctl etc, it would add to a more BSD specific > environment, where standard portable Unix skills was insufficient, > & more time needed to search & learn BSD extras. Every obstacle > costs employers time = money. > This scenario is just a bit too generic for me to be able to relate to, because I've never been in a situation where I would've had to or just randomly used `cat .` to discover junk files. This also isn't really a transferable skill to other modern OS and filesystems, as oftentimes they won't or can't give you anything useful with read(2). That said, I've written a MAC policy that can live atop the current patch to lift all of the restrictions except the sysctl needing to be set: https://people.freebsd.org/~kevans/mac-read_dir.diff -> I could even be convinced fairly easily to commit it, if you'd find that acceptable. The policy ends up looking generically useful, as you can lift just the jail root restriction or you can allow any user to cat a directory. Thanks, Kyle Evans From owner-freebsd-hackers@freebsd.org Sat May 16 17:52:41 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 169212F83B9 for ; Sat, 16 May 2020 17:52:41 +0000 (UTC) (envelope-from kevans@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) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49PXtJ6vyjz3JTp for ; Sat, 16 May 2020 17:52:40 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-qk1-f171.google.com (mail-qk1-f171.google.com [209.85.222.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id D792D81B0 for ; Sat, 16 May 2020 17:52:40 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qk1-f171.google.com with SMTP id y22so6016910qki.3 for ; Sat, 16 May 2020 10:52:40 -0700 (PDT) X-Gm-Message-State: AOAM532qK5YutDwrh5cfVD0xUn8yqMdDOOYD/RIvJ1zYSMY65rzgtDrh UNnHSW6YC1a/Llfhjpfpabo6zWUnJbxZ8F5OzXI= X-Received: by 2002:a37:8c4:: with SMTP id 187mt9369872qki.34.1589651560186; Sat, 16 May 2020 10:52:40 -0700 (PDT) MIME-Version: 1.0 References: <2ea8236f935a4c786a0f4f06ca1d3ea3@udns.ultimatedns.net> <202005161518.04GFIA0a099390@fire.js.berklix.net> In-Reply-To: From: Kyle Evans Date: Sat, 16 May 2020 12:52:29 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [HEADSUP] Disallowing read() of a directory fd Cc: "Julian H. Stacey" , "freebsd-arch@freebsd.org" , "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 May 2020 17:52:41 -0000 On Sat, May 16, 2020 at 11:26 AM Kyle Evans wrote: > > On Sat, May 16, 2020 at 10:18 AM Julian H. Stacey wrote: > > > > Another use of "cat ." is to see names of transient files a tool > > creates, & normaly deletes, if not aborting, so one can find same > > name junk elsewhere, & search for tool causing junk, > > & ensure other data files avoid using names that would be zapped. > > > > While blocking "cat ." might be worked round if not in a jail, & > > or if using fsdb & sysctl etc, it would add to a more BSD specific > > environment, where standard portable Unix skills was insufficient, > > & more time needed to search & learn BSD extras. Every obstacle > > costs employers time = money. > > > > This scenario is just a bit too generic for me to be able to relate > to, because I've never been in a situation where I would've had to or > just randomly used `cat .` to discover junk files. This also isn't > really a transferable skill to other modern OS and filesystems, as > oftentimes they won't or can't give you anything useful with read(2). > > That said, I've written a MAC policy that can live atop the current > patch to lift all of the restrictions except the sysctl needing to be > set: https://people.freebsd.org/~kevans/mac-read_dir.diff -> I could > even be convinced fairly easily to commit it, if you'd find that > acceptable. The policy ends up looking generically useful, as you can > lift just the jail root restriction or you can allow any user to cat a > directory. > I've finished up a manpage for this MAC module and the rest of the build infrastructure, publishing it for review here: https://reviews.freebsd.org/D24862 -> the formal dependency on the previous review has been documented. Thanks, Kyle Evans From owner-freebsd-hackers@freebsd.org Sat May 16 17:58:57 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id AE0572F86FD; Sat, 16 May 2020 17:58:57 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from slim.berklix.org (slim.berklix.org [94.185.90.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "slim.berklix.org", Issuer "slim.berklix.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 49PY1X1fGvz3Jrt; Sat, 16 May 2020 17:58:55 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from mart.js.berklix.net (p2E52C9E4.dip0.t-ipconnect.de [46.82.201.228]) (authenticated bits=128) by slim.berklix.org (8.15.2/8.15.2) with ESMTPSA id 04GHwm6B081960 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 16 May 2020 19:58:52 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id 04GHwldH008345; Sat, 16 May 2020 19:58:48 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.7/8.14.7) with ESMTP id 04GHwbpZ038671; Sat, 16 May 2020 19:58:47 +0200 (CEST) (envelope-from jhs@berklix.com) Message-Id: <202005161758.04GHwbpZ038671@fire.js.berklix.net> To: Kyle Evans cc: "freebsd-arch@freebsd.org" , "freebsd-hackers@freebsd.org" Subject: Re: [HEADSUP] Disallowing read() of a directory fd From: "Julian H. Stacey" Organization: http://berklix.com/jhs http://stolenvotes.uk User-agent: EXMH on FreeBSD http://berklix.com/free/ X-From: http://www.berklix.org/~jhs/ In-reply-to: Your message "Sat, 16 May 2020 11:26:11 -0500." Date: Sat, 16 May 2020 19:58:37 +0200 X-Rspamd-Queue-Id: 49PY1X1fGvz3Jrt X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of jhs@berklix.com has no SPF policy when checking 94.185.90.68) smtp.mailfrom=jhs@berklix.com X-Spamd-Result: default: False [0.21 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[berklix.com]; AUTH_NA(1.00)[]; HAS_ORG_HEADER(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; IP_SCORE(-0.00)[ip: (0.01), ipnet: 94.185.88.0/22(0.01), asn: 33824(-0.00), country: DE(-0.02)]; NEURAL_SPAM_LONG(0.11)[0.107,0]; RCVD_IN_DNSWL_NONE(0.00)[68.90.185.94.list.dnswl.org : 127.0.10.0]; NEURAL_HAM_MEDIUM(-0.80)[-0.797,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:33824, ipnet:94.185.88.0/22, country:DE]; RCVD_TLS_LAST(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[228.201.82.46.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 May 2020 17:58:57 -0000 Kyle Evans wrote: > On Sat, May 16, 2020 at 10:18 AM Julian H. Stacey wrote: > > > > Another use of "cat ." is to see names of transient files a tool > > creates, & normaly deletes, if not aborting, so one can find same > > name junk elsewhere, & search for tool causing junk, > > & ensure other data files avoid using names that would be zapped. > > > > While blocking "cat ." might be worked round if not in a jail, & > > or if using fsdb & sysctl etc, it would add to a more BSD specific > > environment, where standard portable Unix skills was insufficient, > > & more time needed to search & learn BSD extras. Every obstacle > > costs employers time = money. > > > > This scenario is just a bit too generic for me to be able to relate > to, because I've never been in a situation where I would've had to or > just randomly used `cat .` to discover junk files. Yes, it's a rare usage, I dont do it often. > This also isn't > really a transferable skill to other modern OS and filesystems, as > oftentimes they won't or can't give you anything useful with read(2). > > That said, I've written a MAC policy that can live atop the current > patch to lift all of the restrictions except the sysctl needing to be > set: https://people.freebsd.org/~kevans/mac-read_dir.diff -> I could > even be convinced fairly easily to commit it, if you'd find that > acceptable. The policy ends up looking generically useful, as you can > lift just the jail root restriction or you can allow any user to cat a > directory. > > Thanks, > > Kyle Evans Thanks, It's good if its all sysctl without reboot, (taking (phk's I recall) point about an fs not surviving a reboot) It sounds useful, if it allows 3 or is that more ? way choice between eg {old v. new} x { root v. non root } x { inside a jail v. outside } = 8 ? If all of that, I guess we'd just be down to a relaxed consideration about what default mode was for now & later. If there was change there, we'd need to check what policy is about giving advance notice of changes in RELNOTES. If RELNOTES required long notice than wanted , that could be worked round easily by implementing code, & merely issuing notice that defaults would change to new policy later at releasese x.y. I took a quick glance at https://people.freebsd.org/~kevans/mac-read_dir.diff but I'm sorry loads of real life distraction here. I'm sure others will want to read it. Thanks for working hard to cater for all cases ! :-) Cheers -- Julian Stacey, Consultant Systems Engineer, BSD Linux http://berklix.com/jhs/ http://www.berklix.org/corona/#masks Tie 2 handkerchiefs or 1 pillow case. Jobs & economy hit by Corona to be hit again by Crash Brexit 31st Dec. 2020 From owner-freebsd-hackers@freebsd.org Sat May 16 18:28:43 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id AECE22F9802; Sat, 16 May 2020 18:28:43 +0000 (UTC) (envelope-from kevans@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) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49PYgv43vsz3M3p; Sat, 16 May 2020 18:28:43 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-qk1-f177.google.com (mail-qk1-f177.google.com [209.85.222.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 79CD1854C; Sat, 16 May 2020 18:28:43 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qk1-f177.google.com with SMTP id f189so6071628qkd.5; Sat, 16 May 2020 11:28:43 -0700 (PDT) X-Gm-Message-State: AOAM531yf1gg7rAAsFyLhSnwvDajYezNNRBrpSl5cyayLvCxJG4jUQaU HD2Ec2iMi9F4pcpwR9bBtFaF3ef02+YmKFw3mMw= X-Google-Smtp-Source: ABdhPJxc/j7l84amDzf+f7rNCbxmr/AYNYxnQxP1kqm9nbioUJyIAvwtfCuTLmEVKmdiNCzcmU7jypra2xQm8m92RgY= X-Received: by 2002:a37:2711:: with SMTP id n17mr9071974qkn.430.1589653723013; Sat, 16 May 2020 11:28:43 -0700 (PDT) MIME-Version: 1.0 References: <202005161758.04GHwbpZ038671@fire.js.berklix.net> In-Reply-To: <202005161758.04GHwbpZ038671@fire.js.berklix.net> From: Kyle Evans Date: Sat, 16 May 2020 13:28:32 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [HEADSUP] Disallowing read() of a directory fd To: "Julian H. Stacey" Cc: "freebsd-arch@freebsd.org" , "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 May 2020 18:28:43 -0000 On Sat, May 16, 2020 at 12:59 PM Julian H. Stacey wrote: > > Kyle Evans wrote: > > [... snip ...] > > That said, I've written a MAC policy that can live atop the current > > patch to lift all of the restrictions except the sysctl needing to be > > set: https://people.freebsd.org/~kevans/mac-read_dir.diff -> I could > > even be convinced fairly easily to commit it, if you'd find that > > acceptable. The policy ends up looking generically useful, as you can > > lift just the jail root restriction or you can allow any user to cat a > > directory. > > > > Thanks, > > > > Kyle Evans > > Thanks, > It's good if its all sysctl without reboot, (taking (phk's I recall) point > about an fs not surviving a reboot) > Yup- assuming you're not in the perhaps rare situation where you both need this *and* you can't get the kmod loaded, it's all sysctl-based. > It sounds useful, if it allows 3 or is that more ? way choice between eg > {old v. new} x { root v. non root } x { inside a jail v. outside } = 8 ? > It's not quite that flexible because this is harder to capture, it allows three different possibilities: - New behavior - Old behavior - Middle ground, where unprivileged users can't `cat .` but jail root can #3 was thrown in because I suspect someone somewhere may not necessarily care for preservation of any old users' capability to do this, but for those systems where the previously cited 'jail root is root' is true (since I think we agree that that can be the case, but often isn't). > If all of that, I guess we'd just be down to a relaxed consideration about > what default mode was for now & later. > > If there was change there, we'd need to check what policy is about giving > advance notice of changes in RELNOTES. > > If RELNOTES required long notice than wanted , that could be worked round > easily by implementing code, & merely issuing notice that defaults would > change to new policy later at releasese x.y. > Here's how this breaks down; these steps haven't been included in the review thus far because I often just assume that it's clear this will happen: - UPDATING: Users of 13.0-CURRENT will receive notice via UPDATING that this is changing, along with mention of the MAC policy to return to the legacy behavior. Some bumps of this nature are to be expected amongst -CURRENT, and this is how we communicate them to those following along at home. - RELNOTES: This will definitely be included in the 13.0 relnotes. I'm tentatively planning to MFC some of the functionality (security.bsd.allow_read_dir but with a default of 1 to preserve branch behavior) to allow users of stable/12 to turn it off and get the 13.0 behavior earlier if they want or see if it breaks any of their stuff, which I will try and use as a vector to get the future default change into the 12.2 release notes as well so that there's plenty of advance notice. I suspect re@ will happily include it, given the history. > I took a quick glance at > https://people.freebsd.org/~kevans/mac-read_dir.diff but I'm sorry > loads of real life distraction h These kinds of bumps are to be expectedere. I'm sure others will want t > read it. Thanks for working hard to cater for all cases ! :-) > This is fine. =-) Honestly, I have really been trying my best to optimize the outcome for all of our users. I do fully believe at this point in the discussion that the majority of our userbase is best served by changing the default behavior here, and I want to be able to do so without burning community relations. My suspicion is that those of you that do make use of this, do so infrequently and would happily or maybe even usually run a system with: root@viper:~# cat /boot/loader.conf # Of course, this could instead be baked into your kernel config mac_read_dir_load="YES" root@viper:~# cat /etc/sysctl.conf security.mac.read_dir.jail_root=1 # The following perhaps even turned off or commented out to serve just as a reminder, until you actually need it security.bsd.allow_read_dir=1 My working assumption being that you don't often do this as any old unprivileged user, but might be doing so as jail root. Of course, `security.mac.read_dir.jail_root=1` might instead be `security.mac.read_dir.all_users=1` to fully follow the existing behavior. Thanks, Kyle Evans From owner-freebsd-hackers@freebsd.org Sat May 16 21:42:57 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 34EB22FE426; Sat, 16 May 2020 21:42:57 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ultimatedns.net", Issuer "Let's Encrypt Authority X3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 49Pf005vLbz44GF; Sat, 16 May 2020 21:42:56 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (localhost [IPv6:0:0:0:0:0:0:0:1]) by udns.ultimatedns.net (8.15.2/8.15.2) with ESMTPS id 04GLhB29073174 (version=TLSv1.2 cipher=DHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sat, 16 May 2020 14:43:18 -0700 (PDT) (envelope-from bsd-lists@BSDforge.com) X-Mailer: Cypht MIME-Version: 1.0 Cc: "freebsd-arch@freebsd.org" , "freebsd-hackers@freebsd.org" , "Julian H. Stacey" In-Reply-To: From: Chris Reply-To: bsd-lists@BSDforge.com To: Kyle Evans Subject: Re: [HEADSUP] Disallowing read() of a directory fd Date: Sat, 16 May 2020 14:43:17 -0700 Message-Id: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 49Pf005vLbz44GF X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-1.51 / 15.00]; NEURAL_HAM_MEDIUM(-0.56)[-0.557,0]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US]; local_wl_ip(0.00)[24.113.41.81]; NEURAL_HAM_LONG(-0.96)[-0.956,0] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 May 2020 21:42:57 -0000 On Sat, 16 May 2020 13:28:32 -0500 Kyle Evans kevans@freebsd=2Eorg said > On Sat, May 16, 2020 at 12:59 PM Julian H=2E Stacey wrote= : > > > > Kyle Evans wrote: > > > [=2E=2E=2E snip =2E=2E=2E] > > > That said, I've written a MAC policy that can live atop the current > > > patch to lift all of the restrictions except the sysctl needing to be > > > set: https://people=2Efreebsd=2Eorg/~kevans/mac-read_dir=2Ediff -> I could > > > even be convinced fairly easily to commit it, if you'd find that > > > acceptable=2E The policy ends up looking generically useful, as you can > > > lift just the jail root restriction or you can allow any user to cat = a > > > directory=2E > > > > > > Thanks, > > > > > > Kyle Evans > > > > Thanks, > > It's good if its all sysctl without reboot, (taking (phk's I recall) po= int > > about an fs not surviving a reboot) > > >=20 > Yup- assuming you're not in the perhaps rare situation where you both > need this *and* you can't get the kmod loaded, it's all sysctl-based=2E >=20 > > It sounds useful, if it allows 3 or is that more ? way choice between e= g > > {old v=2E new} x { root v=2E non root } x { inside a jail v=2E outside } =3D = 8 ? > > >=20 > It's not quite that flexible because this is harder to capture, it > allows three different possibilities: >=20 > - New behavior > - Old behavior > - Middle ground, where unprivileged users can't `cat =2E` but jail root can >=20 > #3 was thrown in because I suspect someone somewhere may not > necessarily care for preservation of any old users' capability to do > this, but for those systems where the previously cited 'jail root is > root' is true (since I think we agree that that can be the case, but > often isn't)=2E >=20 > > If all of that, I guess we'd just be down to a relaxed consideration ab= out > > what default mode was for now & later=2E > > > > If there was change there, we'd need to check what policy is about givi= ng > > advance notice of changes in RELNOTES=2E > > > > If RELNOTES required long notice than wanted , that could be worked rou= nd > > easily by implementing code, & merely issuing notice that defaults woul= d > > change to new policy later at releasese x=2Ey=2E > > >=20 > Here's how this breaks down; these steps haven't been included in the > review thus far because I often just assume that it's clear this will > happen: >=20 > - UPDATING: Users of 13=2E0-CURRENT will receive notice via UPDATING > that this is changing, along with mention of the MAC policy to return > to the legacy behavior=2E Some bumps of this nature are to be expected > amongst -CURRENT, and this is how we communicate them to those > following along at home=2E >=20 > - RELNOTES: This will definitely be included in the 13=2E0 relnotes=2E I'm > tentatively planning to MFC some of the functionality > (security=2Ebsd=2Eallow_read_dir but with a default of 1 to preserve > branch behavior) to allow users of stable/12 to turn it off and get > the 13=2E0 behavior earlier if they want or see if it breaks any of > their stuff, which I will try and use as a vector to get the future > default change into the 12=2E2 release notes as well so that there's > plenty of advance notice=2E I suspect re@ will happily include it, given > the history=2E >=20 > > I took a quick glance at > > https://people=2Efreebsd=2Eorg/~kevans/mac-read_dir=2Ediff but I'm sorry > > loads of real life distraction h These kinds of bumps are to be expecte= dere=2E > > I'm sure others will want t > > read it=2E Thanks for working hard to cater for all cases ! :-) > > >=20 > This is fine=2E =3D-) Honestly, I have really been trying my best to > optimize the outcome for all of our users=2E I do fully believe at this > point in the discussion that the majority of our userbase is best > served by changing the default behavior here, and I want to be able to > do so without burning community relations=2E >=20 > My suspicion is that those of you that do make use of this, do so > infrequently and would happily or maybe even usually run a system > with: >=20 > root@viper:~# cat /boot/loader=2Econf > # Of course, this could instead be baked into your kernel config > mac_read_dir_load=3D"YES" >=20 > root@viper:~# cat /etc/sysctl=2Econf > security=2Emac=2Eread_dir=2Ejail_root=3D1 > # The following perhaps even turned off or commented out to serve just > as a reminder, until you actually need it > security=2Ebsd=2Eallow_read_dir=3D1 >=20 > My working assumption being that you don't often do this as any old > unprivileged user, but might be doing so as jail root=2E Of course, > `security=2Emac=2Eread_dir=2Ejail_root=3D1` might instead be > `security=2Emac=2Eread_dir=2Eall_users=3D1` to fully follow the existing > behavior=2E >=20 > Thanks, No=2E Thank *you*, Kyle=2E :-) I just want to take this opportunity to thank you for all the work you put into this -- both the semi-anticipated code, and perhaps more significantly, the _social_ work that went into getting this concept into a usable/functional state=2E While I have only glossed over your diff, and therefore can't (yet) reasonably evaluate it=2E Do you anticipate any impact/changes to overall performance? In closing; some of here have been hacking on this code since before Net/1, and are fairly sensitive about some new-comer messing with our UNIX heritage=2E I look back fondly remembering waiting for tubes to warm up, and threading/spooling up tapes=2E I don't remember being too fond of having to wait for someone elses job to finish, so I could use the damn thing=2E ;-) Thanks again! --Chris >=20 > Kyle Evans > _______________________________________________ > freebsd-hackers@freebsd=2Eorg mailing list > https://lists=2Efreebsd=2Eorg/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd=2Eorg= "