From nobody Mon Nov 1 00:47:49 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 2FD1A182BE4C for ; Mon, 1 Nov 2021 00:47:54 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HjDsN1f51z4gJX for ; Mon, 1 Nov 2021 00:47:51 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.16.1/8.16.1) with ESMTPS id 1A10lntC084157 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Sun, 31 Oct 2021 17:47:49 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.16.1/8.16.1/Submit) id 1A10lnFe084156 for freebsd-current@freebsd.org; Sun, 31 Oct 2021 17:47:49 -0700 (PDT) (envelope-from sgk) Date: Sun, 31 Oct 2021 17:47:49 -0700 From: Steve Kargl To: freebsd-current@freebsd.org Subject: Re: access to ld128 system Message-ID: <20211101004749.GA84142@troutmask.apl.washington.edu> References: <20211028222851.GA24101@troutmask.apl.washington.edu> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20211028222851.GA24101@troutmask.apl.washington.edu> X-Rspamd-Queue-Id: 4HjDsN1f51z4gJX X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=washington.edu (policy=none); spf=none (mx1.freebsd.org: domain of sgk@troutmask.apl.washington.edu has no SPF policy when checking 128.95.76.21) smtp.mailfrom=sgk@troutmask.apl.washington.edu X-Spamd-Result: default: False [-0.98 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.96)[-0.957]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.99)[-0.992]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_SPAM_SHORT(0.97)[0.973]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DMARC_POLICY_SOFTFAIL(0.10)[washington.edu : No valid SPF, No valid DKIM,none] X-ThisMailContainsUnwantedMimeParts: N On Thu, Oct 28, 2021 at 03:28:51PM -0700, Steve Kargl wrote: > kib@ recently committed my implementations of cospi[fl], > sinpi[fl], and tanpi[fl]. These functions have been > extensively tested for float, double, and long double > where long double is the Intel 80-bit long double (e.g., > msun/ld80/s_sinpil.c). The 128-bit versions of these > routines have not been tested (e.g., msun/ld128/s_sinpil.c) > > kib pointed me to a system in the FreeBSD, which I have > access to. Unfortunately, that system has double == > long double, and can only test the support for the > weak references. > > Is there a system with 128-bit long double that I can > have access for some testing? > FYI. An individual has provided access to an aarch64 system. A patch has been submitted to fix the ld128 sinpi, cospi, and tanpi. For the record, I did limited testing to not overwhelm the system. The observed max ULP for sinpi and cospi were less than 1.1 ULP, which is slight worse that the desired less than 1 ULP target. This has been traced to the kernel for computing cosl() in the interval [0,pi/4]. I suspect the minmax polynomial coefficients need refinement. -- Steve From nobody Mon Nov 1 08:36:11 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 5E4AE18317AC for ; Mon, 1 Nov 2021 08:36:22 +0000 (UTC) (envelope-from yuri@aetern.org) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4HjRFx2j9Dz4vcC for ; Mon, 1 Nov 2021 08:36:21 +0000 (UTC) (envelope-from yuri@aetern.org) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 108635C00C4 for ; Mon, 1 Nov 2021 04:36:15 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Mon, 01 Nov 2021 04:36:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aetern.org; h= message-id:date:mime-version:subject:to:references:from :in-reply-to:content-type:content-transfer-encoding; s=fm1; bh=a 2MLCOzTV5srVQtqCMTWBSkTHd8ay/mUVQKLXjKJRcI=; b=u+gMJtV4vN3kdb7tv IZinujSFoXzvK46Ahorp12Yo8QmUfCZKwquPdjJiG8wR6mdAAiAVBntxIB+iQlAb dFGUFDem261Ij8cdgnOGl1ckeJBbnBfLIMqf1oWmPJtzBCNy5n9gFucCtsBVPZzg SNTRoQ7+pcp8C6N0mbMUz7nrV7Zgd6zT0qNjpmxPwAIijfcr5e/yd0/GKxkZNvXi jVmZnzMpPRc74aAgwfoeqHFWvAWlzpDd6SJYbn/8yaQC6SrdrITw4QLyhh59kq3W /PLxLhsKjs7P4wjzr0xV8U79qhpApdmT64hpSgc9jc4ck1KAFwEwp/437Cau5V45 0JHjQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=a2MLCOzTV5srVQtqCMTWBSkTHd8ay/mUVQKLXjKJR cI=; b=YyHjqn+xMvxegXT3ysxJCXOkQcFKJ84HZpjH9a9rHwwQzVwwq6Acg2syr U20Z23leumGu9d1F4BC6QpsE+clj9ufj1TK0432DYJz8GurIB2GI4BzK6+gzIBaF MnJ+S0NAude83BSOJoPxmkh2dvyOcwkLY73gTx9MWXXP5Av0kjJL1DTBiO8zj5BM XLoob0jksXCt0NgCHT12dypWETTzH9Oah6xu79Y7BkEUGUdWKzJ77pkD1dKz81Dr ccEq9SWTJxWz+8NNJhhRnAosqHJvbfVl+/FssUM2GKZWoH3Eo1n+mVMHnL5yYjx1 kLGMgIAjDC/yoRXFiVwnaWtOSKlgA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrvdehuddguddulecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepkfffgggfuffvfhfhjggtgfesth ejredttdefjeenucfhrhhomhepjghurhhiuceohihurhhisegrvghtvghrnhdrohhrgheq necuggftrfgrthhtvghrnhepgeehleevueehhffggfetteffieffhfduteduteeuvdehvd fhffdvtefhffejjedvnecuffhomhgrihhnpehfrhgvvggsshgurdhorhhgnecuvehluhhs thgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhephihurhhisegrvghtvg hrnhdrohhrgh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Mon, 1 Nov 2021 04:36:14 -0400 (EDT) Message-ID: <6f99f9bc-8831-aefe-4f73-72f50f8f347b@aetern.org> Date: Mon, 1 Nov 2021 11:36:11 +0300 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.2.1 Subject: Re: Deprecating smbfs(5) and removing it before FreeBSD 14 Content-Language: en-US To: freebsd-current@freebsd.org References: From: Yuri In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4HjRFx2j9Dz4vcC X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=aetern.org header.s=fm1 header.b=u+gMJtV4; dkim=pass header.d=messagingengine.com header.s=fm1 header.b=YyHjqn+x; dmarc=none; spf=pass (mx1.freebsd.org: domain of yuri@aetern.org designates 66.111.4.29 as permitted sender) smtp.mailfrom=yuri@aetern.org X-Spamd-Result: default: False [-2.54 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[aetern.org:s=fm1,messagingengine.com:s=fm1]; FREEFALL_USER(0.00)[yuri]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.29]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; RCVD_COUNT_THREE(0.00)[4]; DMARC_NA(0.00)[aetern.org]; DKIM_TRACE(0.00)[aetern.org:+,messagingengine.com:+]; NEURAL_HAM_SHORT(-0.94)[-0.942]; RWL_MAILSPIKE_POSSIBLE(0.00)[66.111.4.29:from]; NEURAL_HAM_LONG(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.29:from] X-ThisMailContainsUnwantedMimeParts: N Ed Maste wrote: > The smbfs(5) filesystem supports only the obsolete SMBv1 protocol, and > I propose removing it for FreeBSD 14. I know the CHERI folks have been > using it but they plan to migrate away from it. It was broken for > months before they fixed it, so I suspect nobody is using it on > contemporary releases. > > I have review D32707 (https://reviews.freebsd.org/D32707) open to add > this deprecation notice to the man page: > The smbfs filesystem driver supports only the obsolete SMBv1 protocol. > smbfs and userspace counterparts smbutil(1) and mount_smbfs(8) are not > present in FreeBSD 14 and above. Users are advised to evaluate the > sysutils/fusefs-smbnetfs port instead. > > A similar notice would be added to the smbutil and mount_smbfs man > pages, and manu@ suggested having the userland utilities emit a > warning when they are used. > > I am interested in comments, objections, or reports that anyone is in > fact using smbfs. I thought I'd mention the SMB client in illumos which is originally based on FreeBSD one, imported and enhanced by Apple, then imported by Sun, and finally updated to support SMB2/SMB3 in illumos. It has a lot of CDDL code now, but as ZFS shows it's not really a stopper. ISTR there is (was?) also an Apple SMB client (based on FreeBSD) somewhere on their "opensource" site. Just saying that there are other options if someone(TM) is interested in doing the work. From nobody Mon Nov 1 09:19:48 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 51B9418452C8; Mon, 1 Nov 2021 09:19:59 +0000 (UTC) (envelope-from SRS0=42hC=PU=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4HjSDG6nmCz3RHY; Mon, 1 Nov 2021 09:19:58 +0000 (UTC) (envelope-from SRS0=42hC=PU=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 64B4428411; Mon, 1 Nov 2021 10:19:51 +0100 (CET) Received: from illbsd.quip.test (ip-78-45-215-131.net.upcbroadband.cz [78.45.215.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id B809228417; Mon, 1 Nov 2021 10:19:49 +0100 (CET) Subject: Re: Deprecating smbfs(5) and removing it before FreeBSD 14 To: Yuri , freebsd-current@freebsd.org, freebsd-stable References: <6f99f9bc-8831-aefe-4f73-72f50f8f347b@aetern.org> From: Miroslav Lachman <000.fbsd@quip.cz> Message-ID: <79402464-f9e6-5f56-645e-cfd49640032e@quip.cz> Date: Mon, 1 Nov 2021 10:19:48 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 In-Reply-To: <6f99f9bc-8831-aefe-4f73-72f50f8f347b@aetern.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4HjSDG6nmCz3RHY X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On 01/11/2021 09:36, Yuri wrote: > Ed Maste wrote: >> The smbfs(5) filesystem supports only the obsolete SMBv1 protocol, and >> I propose removing it for FreeBSD 14. I know the CHERI folks have been >> using it but they plan to migrate away from it. It was broken for >> months before they fixed it, so I suspect nobody is using it on >> contemporary releases. >> >> I have review D32707 (https://reviews.freebsd.org/D32707) open to add >> this deprecation notice to the man page: >> The smbfs filesystem driver supports only the obsolete SMBv1 protocol. >> smbfs and userspace counterparts smbutil(1) and mount_smbfs(8) are not >> present in FreeBSD 14 and above. Users are advised to evaluate the >> sysutils/fusefs-smbnetfs port instead. >> >> A similar notice would be added to the smbutil and mount_smbfs man >> pages, and manu@ suggested having the userland utilities emit a >> warning when they are used. >> >> I am interested in comments, objections, or reports that anyone is in >> fact using smbfs. > > I thought I'd mention the SMB client in illumos which is originally > based on FreeBSD one, imported and enhanced by Apple, then imported by > Sun, and finally updated to support SMB2/SMB3 in illumos. It has a lot > of CDDL code now, but as ZFS shows it's not really a stopper. > > ISTR there is (was?) also an Apple SMB client (based on FreeBSD) > somewhere on their "opensource" site. > > Just saying that there are other options if someone(TM) is interested in > doing the work. Apple sources can be found there https://opensource.apple.com/source/smb/ with all the history from SMBv1 to SMBv3. The files have original copyright header from 2001 Boris Popov (same as FreeBSD) but otherwise it is very different code due to different kernel interfaces and so on. With Apple and Illumos sources it is possible to have smbfs in FreeBSD upgraded to v2 or v3 but very skilled programmer is needed for this work. And for the past years there is none interested in this work. Miroslav Lachman From nobody Mon Nov 1 15:55:52 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 1EBFA1835B75; Mon, 1 Nov 2021 15:56:01 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-qb1can01on061b.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe5c::61b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Hjd1D5n0Yz3HSC; Mon, 1 Nov 2021 15:56:00 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QNNymklK2UPeA0LcRPC6yicTyje6NOmVD1zLlXoxbk6KAtmaFhZQgfW44Abnwx1owuAgkuidtosnyMExQ1tLllFLpjoCnebUBQUXMIJX2TUP5T2MUtGSL8jsX+o3VoXEMRZeoDymRIzdb5X6eOOUVyQYQb714vWW/3naoDK3HYcGzXWxK2ucJY3KtM/MDKAO2CTQcpp2YxoLnLr6Z0QNrmjrYOgwCiFa8COked+o9Wtvas7x2HBltkdmYK+g4mXJ4Y/R65zXRVt9qRYvcuWiKA1BVypEUZ5bDSwCUXs+qZDriQoVG9eNwNW0oh5zXh8oZQTlhIkje2V/hMyPnUJPpA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=0DatJwa1dJXQhWUZT2O5GwFTWiW9Y36UJZR+k/LhSs4=; b=mnR5reS4rQO8i6AO6L7F9E/oBBZ9GiJO14t+LuCSwoRHNejAwfwnxknur0vJUQ8OfEfnkpKe85NoUhVx0ysFDpblrXmpF8jxyUrYBv50YjYCdIfXz63hOJThoPfgcyZXTv96M7vimG3aWQNOZ5PvPTO7pkcBY026FReJQXOrGm2gNG7lp16HBBMpHXsiFDLh5eBqMuZ+gk6gtQ0SUCg5E/dZ/zwK3OVs/BNcgaPX59pM+DYzk16Go9PRcztx9Bmeq9R57lNTb27ZUIbtkkjcwenBOARRs0hq2857aleOkmg8SCnCeVDYuC24VgZHfqkLM+E6HSkQmDOaZkWPjgGuPg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=uoguelph.ca; dmarc=pass action=none header.from=uoguelph.ca; dkim=pass header.d=uoguelph.ca; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoguelph.ca; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0DatJwa1dJXQhWUZT2O5GwFTWiW9Y36UJZR+k/LhSs4=; b=kZodUrPcwXUgcnlBrobEPum4TnYtb3E+LqkuMCBIzLprdmA/JK92winzS3ditdmfFW42Q1iQ6U/SsCAT9Yd+9aBHxi5UZJNDvWT9Wat+EdSKeG7FU7hSIpn9kOp4M6ITR46wQBZ0HV2dMj8L/Tt3eYxNRrWpv7uCfvQxdgw8fL5lyWuUyv5XElS9SGuZFoeGKxbCY1gNGm1cwy6lovnYfpLfgIpozjWaMttSrWzd2Ax1R+uoIQhV3Pej4inQzA8ZXJey/R2qVPRZUIEgdBgLqp5kenQqFToPviJSBQl8jt2cbSzgAi71Isj+uzOJVXYdHa+6YkFL5P7CR4aeqcXLCA== Received: from YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c00:19::29) by QB1PR01MB3476.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c00:3c::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4649.14; Mon, 1 Nov 2021 15:55:52 +0000 Received: from YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM ([fe80::7091:13ac:171f:1c12]) by YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM ([fe80::7091:13ac:171f:1c12%5]) with mapi id 15.20.4649.019; Mon, 1 Nov 2021 15:55:52 +0000 From: Rick Macklem To: Miroslav Lachman <000.fbsd@quip.cz>, Yuri , "freebsd-current@freebsd.org" , freebsd-stable Subject: Re: Deprecating smbfs(5) and removing it before FreeBSD 14 Thread-Topic: Deprecating smbfs(5) and removing it before FreeBSD 14 Thread-Index: AQHXzvvFA1WWxQSLW0uUJGavCusr2KvuZUQAgABpl4U= Date: Mon, 1 Nov 2021 15:55:52 +0000 Message-ID: References: <6f99f9bc-8831-aefe-4f73-72f50f8f347b@aetern.org> <79402464-f9e6-5f56-645e-cfd49640032e@quip.cz> In-Reply-To: <79402464-f9e6-5f56-645e-cfd49640032e@quip.cz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: suggested_attachment_session_id: 2f489da7-c08d-7d47-366e-c9495048a1f0 x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 46a1a91d-e685-40e6-8a72-08d99d501538 x-ms-traffictypediagnostic: QB1PR01MB3476: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: NbqSr2SZex/oDoXBf4PhJLfGs/adu8G77LJ+M34J5b2jjMF5v1L/QOASuQ1jO1tCzPe3F5QjgqXOZIFrnqOBnhWjxDIW3jNK5Rd5FQlX1Ypm1p6TYYMgPom0cMIzBHds/S4tK2vXzcDJbVMAHRqJ4bfmp7nKKSJ2bvvd2Nt3O0o7Y6JMukPFgKMJ3fMx/l+GXqWPh3c8rEhUfgPdEaKTuH6L2hkuotl83WlQefnhl07cg0pOM79FKXI4P+Px85W4zVE0m3fLhqFEA7HBjd922umVomY92J6TyuKKEDqxAK/amqqiBFgWGu5ORwaCCAjU3wrUb+04QBY4VKPktiXB2ud+4wg4EgGYgSQ8yzAyFg4XrlofBWpARSperMGd8LRd67zmfx9rSOsrf0cXbNiUJQ1bXFXpqAGI0I67MO/j+zFHsq+bn2+T5nbQWtHSDc+tc3Qc6c8o8nS9aVcj5twd1IdnvbslqzeEwVSZkJgOA21MFnbWxAjwD248yb9aMYhYLV7+1hM7aGC8CaNnYZRVdGs7vfVAPPIxO9FAKKMhMa/Z+1GRoloow84Lvq/OM4AE2h7nZXeJPFiPxp1D7+dFDPKO0VGuNA67PsH16tzJooTy/Xp/CbOdDJWttbwdx8E+VYmmrX6pHZPV3uFlqnehYzTVQWIuXfzrw8NgGNhBcNDUZu5NWXC+fuVcF6OZ8LnFCqd0dWPkUZfyLxc64NMtoFRO6naypmI5TKE1RnR1ImS7rU0SL//B7UWL+8ViO6HQ1irGSLOfD7WNGbak87yxm+wMQGRAWPPEmDlhtUxh1ho= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(366004)(2906002)(508600001)(66476007)(38100700002)(66556008)(64756008)(71200400001)(66946007)(66446008)(966005)(122000001)(33656002)(6506007)(83380400001)(76116006)(110136005)(5660300002)(86362001)(7696005)(186003)(8936002)(38070700005)(316002)(8676002)(786003)(52536014)(55016002)(9686003);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?og+LHAe0kNaxF0O0Ix6xsA2z4cAIm4IMtjjGcQ1lG8u/xvBSPiCxv4T+08?= =?iso-8859-1?Q?a9VzNATS7hbLX6KGKWscCZ/nBUl57IjP3T7ttIeRsmNFNJGp1K1voU89HT?= =?iso-8859-1?Q?jf6oEz5JD5ltDmbo81FMzsNCh5pvxYFrRh+dzMuNURCW731DFrOQLcuHpN?= =?iso-8859-1?Q?qZClXOCBt24N0ChEue7RTxNv111GUs6ctiYkkr5IjYBmHu3I1rZ/lbQRme?= =?iso-8859-1?Q?AVwoc4iJkPoYy6htIPneOr1AEqXKofDbV4drMTGLFn+r5Yl3/0w8ofBpvT?= =?iso-8859-1?Q?HS3rMCxnFJHQkk9+TPzLnM+n0PRKZdPdr5/9lOYdpCETpIUE9kuQD6bWGT?= =?iso-8859-1?Q?YkxWD7rCpy3pHoySnKceVLFMh4cs1am9E5FQheHLPDIN7WqSOzVJ/cvGkS?= =?iso-8859-1?Q?+rrAzN9bM8wAS559TVbFo3TSRIVqpwTkuq6GlKQrU20ofKiLbhNBsxKpro?= =?iso-8859-1?Q?OV4Gd9kth2Pq0qhd5iga9sNwwlgxmdv7gLGGcmaTYf/c5L/OgujmPv6Ggs?= =?iso-8859-1?Q?jHRocaR9BrNtK1WsuzyW8GZAempYqHQGw5wC7Xhjh0/CpFvLWgyqQeGvhQ?= =?iso-8859-1?Q?/2NSAG3ced/B4wWy19M1lTfZG6Wi2sKP+ZR4yshKLszXGjF82dYtNRK7i3?= =?iso-8859-1?Q?bbjmSyAfOS9unmbA11XiQmMXf3waFc3IzmDxp1quxxv+YAeK2MXNkH3Wng?= =?iso-8859-1?Q?RAQMV6FccZP14tJX6H+hmuMbcPp2iJfqERV4fKlzNOikcEjrsuxVY4gSdT?= =?iso-8859-1?Q?bqnntd4QmUnnvDA+MbyvJgjmNXAphveGMevLV6SsgVIlnU2Vlj6tCHz6Fy?= =?iso-8859-1?Q?sC3bHY5FjKieK9xg68P/6Xrl1FGbPjZezeIlcyLVWXHbzT/IEMl1s8wLgw?= =?iso-8859-1?Q?4zuz2Xx/Fg0cXIk3o3NKGec1NzFfxs3xQrDwK7sFdWC/jiKthS8pj6XhTN?= =?iso-8859-1?Q?aoTEWd8uGYfvDghQdIIWOXIXVV1zlsgaRco+j7bc0kzLyheSzNm6kPZfxe?= =?iso-8859-1?Q?gdpV9YIZEDsiAGRgysESYZolm4AG+E58OITNuPVPETq63/xfVYREthmaVY?= =?iso-8859-1?Q?HiPKzcQbX9lYWAG+xFOytpDlR6SnTIOg8TpJkpSx3wjomE/k+aP+ze2HGo?= =?iso-8859-1?Q?9tv8gcLn+N98J0XZvwk0UzoSwWcK8ekE5fs30daQ5F8tVXKhbXqmGMBiTG?= =?iso-8859-1?Q?BjhGSot9nCNTW1x1XCqtquXaLGBErTJ08K/B/ANVeXg50vJH8IGQufppug?= =?iso-8859-1?Q?OrtmXGZdxTdJUvRMrdOoxXbbVm6CGPVHiRhCqhuUjehzfECDJfkIJjShfp?= =?iso-8859-1?Q?NrkdbyOT9VKBqoiO3FQZZp1hvZbMA87gjGP89coUOKCd4tJQPRxyq+YWmI?= =?iso-8859-1?Q?N5YsNAN1mMoe1S/HkyDuGRXSDhcX9me/5PDmWZ0olECa6Mff4zFayIGPn0?= =?iso-8859-1?Q?DguPoPqBv/pELveb7fVMaKVhfs3XpgBdst7A6zt8NfMTYI9jTqvWV83DSK?= =?iso-8859-1?Q?uLxqodMXDV9mqAPlYWdacKvD1HaA6Em0AUuntuJ4urRPViSZkkLNX976We?= =?iso-8859-1?Q?lKQ/j8GAlNb/pYRhFmRVJ9tGIIzCCo+O8HZSpqCmUBz3wmYUDKjz5akKwS?= =?iso-8859-1?Q?wEVsmblIVqBf94Q9ldBoQs0C3uj2fm6Y4Cvtb4mgaxmTWr0/Y/1yEeX+Ju?= =?iso-8859-1?Q?08Wfq7cknoRhY/uYASxkMBhAGz9pBZg+ffbL5iYeyTFMl7JzkwZp5WKo1x?= =?iso-8859-1?Q?CRXA=3D=3D?= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 46a1a91d-e685-40e6-8a72-08d99d501538 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Nov 2021 15:55:52.7957 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: R1Nosu5IyWHxBKhmk2ppsVDmugQxPyrya2f2Cf383o16ih+1N+zS8dG9RHl4LXh5oVgqmaMkUKFL7J5xgU0vLQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: QB1PR01MB3476 X-Rspamd-Queue-Id: 4Hjd1D5n0Yz3HSC X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N Miroslav Lachman wrote:=0A= [good stuff snipped]=0A= > Apple sources can be found there=0A= > https://opensource.apple.com/source/smb/ with all the history from SMBv1= =0A= > to SMBv3. The files have original copyright header from 2001 Boris Popov= =0A= > (same as FreeBSD) but otherwise it is very different code due to=0A= > different kernel interfaces and so on.=0A= > With Apple and Illumos sources it is possible to have smbfs in FreeBSD=0A= > upgraded to v2 or v3 but very skilled programmer is needed for this=0A= > work. And for the past years there is none interested in this work.=0A= =0A= Although I agree that it would be a non-trivial exercise, a lot of the Appl= e=0A= differences are in the "smoke and mirrors" category.=0A= Around OSX 10.4, they changed their VFS/VOP to typedefs and accessor=0A= functions. For example:=0A= "struct vnode *vp" became "vnode_t vp"=0A= and "vp->v_type" became "vnode_type(vp)"=0A= =0A= Ten years ago, the actual semantics were very close to what FreeBSD used.= =0A= If you look at sys/fs/nfs/nfskpiport.h in older sources (around FreeBSD 10)= ,=0A= you'll see a bunch of macros I used to allow the Apple port to also build/r= un=0A= on FreeBSD (a couple, such as vnode_t are still left because I've never got= ten=0A= around to doing the edit to replace them).=0A= =0A= The hard part will be dealing with the actual VFS/VOP semantics changes tha= t=0A= have occurred in the last 10 years.=0A= =0A= Did they stick APSLs on the files? (If so, I think it could still be ok, si= nce the APSL=0A= is a lot like the CDDL. However, I'm not sure if the APSL has ever been ble= ssed=0A= by FreeBSD as of yet?)=0A= =0A= Don't assume anything will happen, but I *might* take a look in the winter,= =0A= since outstanding NFS changes should be done by the end of 2021.=0A= =0A= It does sound like there is some interest in this and that fuse doesn't sol= ve=0A= the problem (at least for everyone).=0A= =0A= rick=0A= =0A= Miroslav Lachman=0A= =0A= From nobody Mon Nov 1 18:27:52 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 2CC201838BB1; Mon, 1 Nov 2021 18:28:16 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io1-f46.google.com (mail-io1-f46.google.com [209.85.166.46]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HjhNw0XXqz4tn2; Mon, 1 Nov 2021 18:28:16 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io1-f46.google.com with SMTP id d63so22709133iof.4; Mon, 01 Nov 2021 11:28:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kysNLc2G/SQA2Lm9rhro+dVmi5wGje0VFwRWBszsEmc=; b=TBUohFlYGSIzlVzAdPYjRMAfEapfrX1Ac7wIAy/CITp2cZq+TP0gd7V5XJOYbDzk4D n5g0nJz0kjqZmV1IbAHEv6gIeA+4uJKZTLKrUsq0CcdRLgbngCEk0a5amyyJ5RUuvoUR swO56p8xe/EOAIQuCbqVtdEic8xkPcrNZP+OffPz+LG7mR/cbiE4xqUuaNimFcIecZXA Gf8VXVOycbe6eBU5J4LU3PVuHHFolDaDM3w7KbZROTMPCW2h3k3SwH3hC0g16Eg8Wod4 ig3jCa9KsIGLjHfyvW9K+ZvaiYzJQILPedDcQZhcrLswd6gtNYkErGBwStSF/a19W4vO ChqA== X-Gm-Message-State: AOAM533ecl59LLWcd4a8PkkUbk7MNMhPeSG4T82WKg8NL5xSwO6eRlqF YkmpXismdLhiG5KmIJcKFpZVQft1+DeQxtcmstyxfpg1xFE= X-Google-Smtp-Source: ABdhPJwwkvlt0dr00wuHbSgbpew4q3hgIYQeKXb/+7b2Ca8weHCZ4JbOqMY6bv5sMEItPA1GqYzEZPPs4BjoNwb6GnA= X-Received: by 2002:a02:7105:: with SMTP id n5mr23394075jac.64.1635791295501; Mon, 01 Nov 2021 11:28:15 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <6f99f9bc-8831-aefe-4f73-72f50f8f347b@aetern.org> <79402464-f9e6-5f56-645e-cfd49640032e@quip.cz> In-Reply-To: From: Ed Maste Date: Mon, 1 Nov 2021 14:27:52 -0400 Message-ID: Subject: Re: Deprecating smbfs(5) and removing it before FreeBSD 14 To: Rick Macklem Cc: Miroslav Lachman <000.fbsd@quip.cz>, Yuri , "freebsd-current@freebsd.org" , freebsd-stable Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4HjhNw0XXqz4tn2 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Mon, 1 Nov 2021 at 11:56, Rick Macklem wrote: > > Did they stick APSLs on the files? (If so, I think it could still be ok, since the APSL > is a lot like the CDDL. However, I'm not sure if the APSL has ever been blessed > by FreeBSD as of yet?) I had a quick look at the Illumos kernel files and it appears each file is licensed under only one of 4-clause BSD, APSL, or CDDL, depending on where it originated. Files from Boris Popov's original FreeBSD implementation have the 4-clause BSD license, followed by something like: /* * Copyright (c) 2008, 2010, Oracle and/or its affiliates. All rights reserved. * Portions Copyright (C) 2001 - 2013 Apple Inc. All rights reserved. * Copyright 2018 Nexenta Systems, Inc. All rights reserved. */ There are 28 BSD-licensed kernel files, 5 APSL, and 13 CDDL. I think that having an smbfs kernel module in the tree using a combination of those licenses is fine. (This isn't on behalf of core@ and of course due diligence needs to be done, but from a high level it seems reasonable.) From nobody Mon Nov 1 19:50:01 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 29C04184095F for ; Mon, 1 Nov 2021 19:50:13 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ua1-x935.google.com (mail-ua1-x935.google.com [IPv6:2607:f8b0:4864:20::935]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HjkCT0PCNz3s2M for ; Mon, 1 Nov 2021 19:50:13 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ua1-x935.google.com with SMTP id e2so33846537uax.7 for ; Mon, 01 Nov 2021 12:50:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sPGbSD5Q2qQVeU/jlWlSN1u15ovZgb/2BqCNwty7K5c=; b=grSgQg90bpoDyYTcmt2ARYSgg54h7h3sHN8511+mLsOlZ2U5zXvBxXYtfgHsvQRI7w KitFal8VQ1DSDC5boV4IGKbG6FsW7/BAtPti5tr5RzxM+pRFSV51HM92/v/GUGJXbsG7 8Wa1vkWPC0dvxfjoRLQXAGAyqF2QSoS/4YkriB7B36x0ZewgJJFNly3GPiTPGfvVy235 aB9tv+qHbuQEwHaTA00RrkZ733c8ryDy4HNwnR9FIUC1DeqYU/NLnYvSphNvcluz4rGU A184DPzy+OMo7jErhs7G/52iwxxNeWqiL/RPF12trMWlWbb5zJ1cwZdasiyaDXrYSSnN ysJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sPGbSD5Q2qQVeU/jlWlSN1u15ovZgb/2BqCNwty7K5c=; b=3t7ZcskHVqgO5W/s6lf9Fy60JULNQ3CnFKYnb5CTwmWPioMDo363zq2qBS9vixQake jbflJ4Q5EAl7MKsRmIJm5nInLfryoD923+xTUYr3Fi3xB0ynO2FstxEQLnRWc/auyHjP eAzFavaPX5cLLBcHKWi86c8YGHEF/Ry7AfK4eJG1wcGGkbyuwT5QS2MmPeWOuxmMGLNR UNuGJ1CngQmeXdL9hntpCScuXWvQGArMH7dY2vM9ntt7BidZvyGnceV8vNN1DW+pe1HB kDxAYqSw6EzA1QyJzE0kaNrpF3fGSBczaXaHOoMnOcMsjDEKP+T+lliX6bKUFePzVrDH j8fA== X-Gm-Message-State: AOAM530Of+jB4d7lHMomSQvzUI0K4n0WRoPX/wwQA9Ei5a4wVMyfWt3X Qt02cRyiMeXfTaWenstlYirf/EV1cZVYmVnenQ5mrA== X-Google-Smtp-Source: ABdhPJwq0ntnGWPlz5jlx/CZDT5mAHPjqbLAnwq4AXnqztbH3nvHKWMMmJ8tT0/rwLMp/fNV8k90VkDdYup+b53M9/k= X-Received: by 2002:ab0:3d07:: with SMTP id f7mr9169156uax.11.1635796212503; Mon, 01 Nov 2021 12:50:12 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <6f99f9bc-8831-aefe-4f73-72f50f8f347b@aetern.org> <79402464-f9e6-5f56-645e-cfd49640032e@quip.cz> In-Reply-To: From: Warner Losh Date: Mon, 1 Nov 2021 13:50:01 -0600 Message-ID: Subject: Re: Deprecating smbfs(5) and removing it before FreeBSD 14 To: Ed Maste Cc: Rick Macklem , Miroslav Lachman <000.fbsd@quip.cz>, Yuri , "freebsd-current@freebsd.org" , freebsd-stable Content-Type: multipart/alternative; boundary="0000000000002bee6a05cfbf7c72" X-Rspamd-Queue-Id: 4HjkCT0PCNz3s2M X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y --0000000000002bee6a05cfbf7c72 Content-Type: text/plain; charset="UTF-8" On Mon, Nov 1, 2021 at 12:29 PM Ed Maste wrote: > On Mon, 1 Nov 2021 at 11:56, Rick Macklem wrote: > > > > Did they stick APSLs on the files? (If so, I think it could still be ok, > since the APSL > > is a lot like the CDDL. However, I'm not sure if the APSL has ever been > blessed > > by FreeBSD as of yet?) > > I had a quick look at the Illumos kernel files and it appears each > file is licensed under only one of 4-clause BSD, APSL, or CDDL, > depending on where it originated. > > Files from Boris Popov's original FreeBSD implementation have the > 4-clause BSD license, followed by something like: > /* > * Copyright (c) 2008, 2010, Oracle and/or its affiliates. All rights > reserved. > * Portions Copyright (C) 2001 - 2013 Apple Inc. All rights reserved. > * Copyright 2018 Nexenta Systems, Inc. All rights reserved. > */ > > There are 28 BSD-licensed kernel files, 5 APSL, and 13 CDDL. I think > that having an smbfs kernel module in the tree using a combination of > those licenses is fine. (This isn't on behalf of core@ and of course > due diligence needs to be done, but from a high level it seems > reasonable.) > Yea, I took a quick look and came to a similar conclusion: this code base is likely fine for inclusion from a license perspective, but would take some doing to get it working on FreeBSD robustly for all the reasons that Rick delved into far better than I can... Warner --0000000000002bee6a05cfbf7c72-- From nobody Mon Nov 1 21:47:03 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4C5D5182B38E; Mon, 1 Nov 2021 21:47:10 +0000 (UTC) (envelope-from SRS0=42hC=PU=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4HjmpQ07Gtz55KN; Mon, 1 Nov 2021 21:47:09 +0000 (UTC) (envelope-from SRS0=42hC=PU=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 4CB1128416; Mon, 1 Nov 2021 22:47:07 +0100 (CET) Received: from illbsd.quip.test (ip-78-45-215-131.net.upcbroadband.cz [78.45.215.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id B604528411; Mon, 1 Nov 2021 22:47:05 +0100 (CET) Subject: Re: Deprecating smbfs(5) and removing it before FreeBSD 14 To: Rick Macklem , "freebsd-current@freebsd.org" , freebsd-stable References: <6f99f9bc-8831-aefe-4f73-72f50f8f347b@aetern.org> <79402464-f9e6-5f56-645e-cfd49640032e@quip.cz> From: Miroslav Lachman <000.fbsd@quip.cz> Cc: Yuri Message-ID: <7db04ed9-39eb-7163-ce92-9a52c5f7d302@quip.cz> Date: Mon, 1 Nov 2021 22:47:03 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4HjmpQ07Gtz55KN X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On 01/11/2021 16:55, Rick Macklem wrote: > Miroslav Lachman wrote: > [good stuff snipped] >> Apple sources can be found there >> https://opensource.apple.com/source/smb/ with all the history from SMBv1 >> to SMBv3. The files have original copyright header from 2001 Boris Popov >> (same as FreeBSD) but otherwise it is very different code due to >> different kernel interfaces and so on. >> With Apple and Illumos sources it is possible to have smbfs in FreeBSD >> upgraded to v2 or v3 but very skilled programmer is needed for this >> work. And for the past years there is none interested in this work. > > Although I agree that it would be a non-trivial exercise, a lot of the Apple > differences are in the "smoke and mirrors" category. > Around OSX 10.4, they changed their VFS/VOP to typedefs and accessor > functions. For example: > "struct vnode *vp" became "vnode_t vp" > and "vp->v_type" became "vnode_type(vp)" > > Ten years ago, the actual semantics were very close to what FreeBSD used. > If you look at sys/fs/nfs/nfskpiport.h in older sources (around FreeBSD 10), > you'll see a bunch of macros I used to allow the Apple port to also build/run > on FreeBSD (a couple, such as vnode_t are still left because I've never gotten > around to doing the edit to replace them). If I see it right even the 10 years old Apple version of smbfs has support for SMBv2 so if this old version is closer to FreeBSD kernel / smbfs it can be a good starting point to merge changes to our smbfs to have SMBv2 support on FreeBSD. > The hard part will be dealing with the actual VFS/VOP semantics changes that > have occurred in the last 10 years. > > Did they stick APSLs on the files? (If so, I think it could still be ok, since the APSL > is a lot like the CDDL. However, I'm not sure if the APSL has ever been blessed > by FreeBSD as of yet?) The old versions of smbfs has original copyright header and no other license. Newer version has some added files with different header with APSL license. For example https://opensource.apple.com/source/smb/smb-759.40.1/kernel/smbfs/smbfs_subr_2.h.auto.html If license is a problem then I think it can live with APSL in the ports tree as a loadable kernel module. Maybe this will be the easier for development too? > Don't assume anything will happen, but I *might* take a look in the winter, > since outstanding NFS changes should be done by the end of 2021. I really appreciate your endless work on NFS on FreeBSD. Without your work the NFS will be lacking behind industry standards similar to what we see with smbfs. And if you will have some spare time to take a look on smbfs and maybe solve the SMBv2 / SMBv3 problem you will be my hero. I am waiting for it for many years and I know I am not alone who needs working SMB / CIFS on FreeBSD. > It does sound like there is some interest in this and that fuse doesn't solve > the problem (at least for everyone). Yes, there is an interest. It was discussed few times in the past in the mailing lists and web forums.freebsd.org but without anybody willing to touch the code. FUSE alternatives have so many problems with performance, stability and configuration. https://forums.freebsd.org/threads/getting-smbnetfs-to-work.78413/ Kind regards Miroslav Lachman From nobody Tue Nov 2 14:16:35 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id C578918481B7; Tue, 2 Nov 2021 14:16:48 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from mail.protected-networks.net (mail.protected-networks.net [IPv6:2001:470:8d59:1::8]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mail.protected-networks.net", Issuer "R3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HkBmH6kHhz4lpg; Tue, 2 Nov 2021 14:16:47 +0000 (UTC) (envelope-from imb@protected-networks.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d= protected-networks.net; h=content-transfer-encoding:content-type :content-type:subject:subject:from:from:content-language :user-agent:mime-version:date:date:message-id; s=201508; t= 1635862596; bh=iRlGmrtDmoONXbJuuLNSpVtiCMwm+xUCKCU3MzK3uoQ=; b=g n8LiEzP00Vz4t92MnwaAgMRH7rYUbm8UpeKbn0rgQFjHMQvrWVibG320D8KUTCe5 e3ZqUiHv5WbQVb8+7wAlvFR6P5hqSdoP0hQtW25U4MGKpXRBne9CWyMczvLP0lZy NjTg5jKUo3PVFdgi5/F7FMCHVRJ+mpfW2DCmcEzqwA= Received: from [192.168.1.10] (toshi.auburn.protected-networks.net [192.168.1.10]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: imb@mail.protected-networks.net) by mail.protected-networks.net (Postfix) with ESMTPSA id 2F6FD46E31; Tue, 2 Nov 2021 10:16:36 -0400 (EDT) Message-ID: Date: Tue, 2 Nov 2021 10:16:35 -0400 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Content-Language: en-NZ To: freebsd-current Cc: "freebsd-emulation@freebsd.org" Subject: current now panics when starting VBox VM Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4HkBmH6kHhz4lpg X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=protected-networks.net header.s=201508 header.b="g n8LiEz"; dmarc=pass (policy=reject) header.from=protected-networks.net; spf=pass (mx1.freebsd.org: domain of imb@protected-networks.net designates 2001:470:8d59:1::8 as permitted sender) smtp.mailfrom=imb@protected-networks.net X-Spamd-Result: default: False [-0.08 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[protected-networks.net:s=201508]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_SHORT(0.92)[0.915]; ARC_NA(0.00)[]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; DKIM_TRACE(0.00)[protected-networks.net:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[protected-networks.net,reject]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] Reply-To: imb@protected-networks.net From: Michael Butler via freebsd-current X-Original-From: Michael Butler X-ThisMailContainsUnwantedMimeParts: N On current as of this morning (I haven't tried to bisect yet) .. FreeBSD toshi.auburn.protected-networks.net 14.0-CURRENT FreeBSD 14.0-CURRENT #42 main-a670e1c13a: Tue Nov 2 09:29:28 EDT 2021 root@toshi.auburn.protected-networks.net:/usr/obj/usr/src/amd64.amd64/sys/TOSHI amd64 .. with either graphics/drm-devel-kmod or graphics/drm-current-kmod, trying to start a VirtualBox VM triggers this panic .. Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x0 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff80ca5564 stack pointer = 0x28:0xfffffe011c036b80 frame pointer = 0x28:0xfffffe011c036b80 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 = 1378 (plasmashell) trap number = 12 WARNING !drm_modeset_is_locked(&crtc->mutex) failed at /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:621 #0 0xffffffff81ec2c63 at linux_dump_stack+0x23 #1 0xffffffff81e403b2 at drm_atomic_helper_check_modeset+0xb2 #2 0xffffffff81d3870c at intel_atomic_check+0x8c #3 0xffffffff81e3f383 at drm_atomic_check_only+0x423 #4 0xffffffff81e3f783 at drm_atomic_commit+0x13 #5 0xffffffff81e4c2e8 at drm_client_modeset_commit_atomic+0x148 #6 0xffffffff81e4c046 at drm_client_modeset_commit_force+0x66 #7 0xffffffff81e8bf1a at drm_fb_helper_restore_fbdev_mode_unlocked+0x7a #8 0xffffffff81e85ef6 at vt_kms_postswitch+0x166 #9 0xffffffff807a59f0 at vt_window_switch+0x120 #10 0xffffffff807a2b4f at vtterm_cngrab+0x4f #11 0xffffffff80865716 at cngrab+0x16 #12 0xffffffff808cbe1c at vpanic+0xec #13 0xffffffff808cbd23 at panic+0x43 #14 0xffffffff80ca928c at trap_fatal+0x2dc #15 0xffffffff80ca962f at trap_pfault+0x32f #16 0xffffffff80ca8a3c at trap+0x23c #17 0xffffffff80c81fc8 at calltrap+0x8 WARNING !drm_modeset_is_locked(&crtc->mutex) failed at /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:621 #0 0xffffffff81ec2c63 at linux_dump_stack+0x23 #1 0xffffffff81e403b2 at drm_atomic_helper_check_modeset+0xb2 #2 0xffffffff81d3870c at intel_atomic_check+0x8c #3 0xffffffff81e3f383 at drm_atomic_check_only+0x423 #4 0xffffffff81e3f783 at drm_atomic_commit+0x13 #5 0xffffffff81e4c2e8 at drm_client_modeset_commit_atomic+0x148 #6 0xffffffff81e4c046 at drm_client_modeset_commit_force+0x66 #7 0xffffffff81e8bf1a at drm_fb_helper_restore_fbdev_mode_unlocked+0x7a #8 0xffffffff81e85ef6 at vt_kms_postswitch+0x166 #9 0xffffffff807a59f0 at vt_window_switch+0x120 #10 0xffffffff807a2b4f at vtterm_cngrab+0x4f #11 0xffffffff80865716 at cngrab+0x16 #12 0xffffffff808cbe1c at vpanic+0xec #13 0xffffffff808cbd23 at panic+0x43 #14 0xffffffff80ca928c at trap_fatal+0x2dc #15 0xffffffff80ca962f at trap_pfault+0x32f #16 0xffffffff80ca8a3c at trap+0x23c #17 0xffffffff80c81fc8 at calltrap+0x8 WARNING !drm_modeset_is_locked(&crtc->mutex) failed at /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:621 #0 0xffffffff81ec2c63 at linux_dump_stack+0x23 #1 0xffffffff81e403b2 at drm_atomic_helper_check_modeset+0xb2 #2 0xffffffff81d3870c at intel_atomic_check+0x8c #3 0xffffffff81e3f383 at drm_atomic_check_only+0x423 #4 0xffffffff81e3f783 at drm_atomic_commit+0x13 #5 0xffffffff81e4c2e8 at drm_client_modeset_commit_atomic+0x148 #6 0xffffffff81e4c046 at drm_client_modeset_commit_force+0x66 #7 0xffffffff81e8bf1a at drm_fb_helper_restore_fbdev_mode_unlocked+0x7a #8 0xffffffff81e85ef6 at vt_kms_postswitch+0x166 #9 0xffffffff807a59f0 at vt_window_switch+0x120 #10 0xffffffff807a2b4f at vtterm_cngrab+0x4f #11 0xffffffff80865716 at cngrab+0x16 #12 0xffffffff808cbe1c at vpanic+0xec #13 0xffffffff808cbd23 at panic+0x43 #14 0xffffffff80ca928c at trap_fatal+0x2dc #15 0xffffffff80ca962f at trap_pfault+0x32f #16 0xffffffff80ca8a3c at trap+0x23c #17 0xffffffff80c81fc8 at calltrap+0x8 WARNING !drm_modeset_is_locked(&dev->mode_config.connection_mutex) failed at /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:666 #0 0xffffffff81ec2c63 at linux_dump_stack+0x23 #1 0xffffffff81e40542 at drm_atomic_helper_check_modeset+0x242 #2 0xffffffff81d3870c at intel_atomic_check+0x8c #3 0xffffffff81e3f383 at drm_atomic_check_only+0x423 #4 0xffffffff81e3f783 at drm_atomic_commit+0x13 #5 0xffffffff81e4c2e8 at drm_client_modeset_commit_atomic+0x148 #6 0xffffffff81e4c046 at drm_client_modeset_commit_force+0x66 #7 0xffffffff81e8bf1a at drm_fb_helper_restore_fbdev_mode_unlocked+0x7a #8 0xffffffff81e85ef6 at vt_kms_postswitch+0x166 #9 0xffffffff807a59f0 at vt_window_switch+0x120 #10 0xffffffff807a2b4f at vtterm_cngrab+0x4f #11 0xffffffff80865716 at cngrab+0x16 #12 0xffffffff808cbe1c at vpanic+0xec #13 0xffffffff808cbd23 at panic+0x43 #14 0xffffffff80ca928c at trap_fatal+0x2dc #15 0xffffffff80ca962f at trap_pfault+0x32f #16 0xffffffff80ca8a3c at trap+0x23c #17 0xffffffff80c81fc8 at calltrap+0x8 WARNING !drm_modeset_is_locked(&plane->mutex) failed at /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:871 #0 0xffffffff81ec2c63 at linux_dump_stack+0x23 #1 0xffffffff81e4160f at drm_atomic_helper_check_planes+0xaf #2 0xffffffff81d39847 at intel_atomic_check+0x11c7 #3 0xffffffff81e3f383 at drm_atomic_check_only+0x423 #4 0xffffffff81e3f783 at drm_atomic_commit+0x13 #5 0xffffffff81e4c2e8 at drm_client_modeset_commit_atomic+0x148 #6 0xffffffff81e4c046 at drm_client_modeset_commit_force+0x66 #7 0xffffffff81e8bf1a at drm_fb_helper_restore_fbdev_mode_unlocked+0x7a #8 0xffffffff81e85ef6 at vt_kms_postswitch+0x166 #9 0xffffffff807a59f0 at vt_window_switch+0x120 #10 0xffffffff807a2b4f at vtterm_cngrab+0x4f #11 0xffffffff80865716 at cngrab+0x16 #12 0xffffffff808cbe1c at vpanic+0xec #13 0xffffffff808cbd23 at panic+0x43 #14 0xffffffff80ca928c at trap_fatal+0x2dc #15 0xffffffff80ca962f at trap_pfault+0x32f #16 0xffffffff80ca8a3c at trap+0x23c #17 0xffffffff80c81fc8 at calltrap+0x8 WARNING !drm_modeset_is_locked(&plane->mutex) failed at /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:871 #0 0xffffffff81ec2c63 at linux_dump_stack+0x23 #1 0xffffffff81e4160f at drm_atomic_helper_check_planes+0xaf #2 0xffffffff81d39847 at intel_atomic_check+0x11c7 #3 0xffffffff81e3f383 at drm_atomic_check_only+0x423 #4 0xffffffff81e3f783 at drm_atomic_commit+0x13 #5 0xffffffff81e4c2e8 at drm_client_modeset_commit_atomic+0x148 #6 0xffffffff81e4c046 at drm_client_modeset_commit_force+0x66 #7 0xffffffff81e8bf1a at drm_fb_helper_restore_fbdev_mode_unlocked+0x7a #8 0xffffffff81e85ef6 at vt_kms_postswitch+0x166 #9 0xffffffff807a59f0 at vt_window_switch+0x120 #10 0xffffffff807a2b4f at vtterm_cngrab+0x4f #11 0xffffffff80865716 at cngrab+0x16 #12 0xffffffff808cbe1c at vpanic+0xec #13 0xffffffff808cbd23 at panic+0x43 #14 0xffffffff80ca928c at trap_fatal+0x2dc #15 0xffffffff80ca962f at trap_pfault+0x32f #16 0xffffffff80ca8a3c at trap+0x23c #17 0xffffffff80c81fc8 at calltrap+0x8 WARNING !drm_modeset_is_locked(&plane->mutex) failed at /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:871 #0 0xffffffff81ec2c63 at linux_dump_stack+0x23 #1 0xffffffff81e4160f at drm_atomic_helper_check_planes+0xaf #2 0xffffffff81d39847 at intel_atomic_check+0x11c7 #3 0xffffffff81e3f383 at drm_atomic_check_only+0x423 #4 0xffffffff81e3f783 at drm_atomic_commit+0x13 #5 0xffffffff81e4c2e8 at drm_client_modeset_commit_atomic+0x148 #6 0xffffffff81e4c046 at drm_client_modeset_commit_force+0x66 #7 0xffffffff81e8bf1a at drm_fb_helper_restore_fbdev_mode_unlocked+0x7a #8 0xffffffff81e85ef6 at vt_kms_postswitch+0x166 #9 0xffffffff807a59f0 at vt_window_switch+0x120 #10 0xffffffff807a2b4f at vtterm_cngrab+0x4f #11 0xffffffff80865716 at cngrab+0x16 #12 0xffffffff808cbe1c at vpanic+0xec #13 0xffffffff808cbd23 at panic+0x43 #14 0xffffffff80ca928c at trap_fatal+0x2dc #15 0xffffffff80ca962f at trap_pfault+0x32f #16 0xffffffff80ca8a3c at trap+0x23c #17 0xffffffff80c81fc8 at calltrap+0x8 WARNING !drm_modeset_is_locked(&plane->mutex) failed at /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:871 #0 0xffffffff81ec2c63 at linux_dump_stack+0x23 #1 0xffffffff81e4160f at drm_atomic_helper_check_planes+0xaf #2 0xffffffff81d39847 at intel_atomic_check+0x11c7 #3 0xffffffff81e3f383 at drm_atomic_check_only+0x423 #4 0xffffffff81e3f783 at drm_atomic_commit+0x13 #5 0xffffffff81e4c2e8 at drm_client_modeset_commit_atomic+0x148 #6 0xffffffff81e4c046 at drm_client_modeset_commit_force+0x66 #7 0xffffffff81e8bf1a at drm_fb_helper_restore_fbdev_mode_unlocked+0x7a #8 0xffffffff81e85ef6 at vt_kms_postswitch+0x166 #9 0xffffffff807a59f0 at vt_window_switch+0x120 #10 0xffffffff807a2b4f at vtterm_cngrab+0x4f #11 0xffffffff80865716 at cngrab+0x16 #12 0xffffffff808cbe1c at vpanic+0xec #13 0xffffffff808cbd23 at panic+0x43 #14 0xffffffff80ca928c at trap_fatal+0x2dc #15 0xffffffff80ca962f at trap_pfault+0x32f #16 0xffffffff80ca8a3c at trap+0x23c #17 0xffffffff80c81fc8 at calltrap+0x8 WARNING !drm_modeset_is_locked(&plane->mutex) failed at /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:871 #0 0xffffffff81ec2c63 at linux_dump_stack+0x23 #1 0xffffffff81e4160f at drm_atomic_helper_check_planes+0xaf #2 0xffffffff81d39847 at intel_atomic_check+0x11c7 #3 0xffffffff81e3f383 at drm_atomic_check_only+0x423 #4 0xffffffff81e3f783 at drm_atomic_commit+0x13 #5 0xffffffff81e4c2e8 at drm_client_modeset_commit_atomic+0x148 #6 0xffffffff81e4c046 at drm_client_modeset_commit_force+0x66 #7 0xffffffff81e8bf1a at drm_fb_helper_restore_fbdev_mode_unlocked+0x7a #8 0xffffffff81e85ef6 at vt_kms_postswitch+0x166 #9 0xffffffff807a59f0 at vt_window_switch+0x120 #10 0xffffffff807a2b4f at vtterm_cngrab+0x4f #11 0xffffffff80865716 at cngrab+0x16 #12 0xffffffff808cbe1c at vpanic+0xec #13 0xffffffff808cbd23 at panic+0x43 #14 0xffffffff80ca928c at trap_fatal+0x2dc #15 0xffffffff80ca962f at trap_pfault+0x32f #16 0xffffffff80ca8a3c at trap+0x23c #17 0xffffffff80c81fc8 at calltrap+0x8 WARNING !drm_modeset_is_locked(&plane->mutex) failed at /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:871 #0 0xffffffff81ec2c63 at linux_dump_stack+0x23 #1 0xffffffff81e4160f at drm_atomic_helper_check_planes+0xaf #2 0xffffffff81d39847 at intel_atomic_check+0x11c7 #3 0xffffffff81e3f383 at drm_atomic_check_only+0x423 #4 0xffffffff81e3f783 at drm_atomic_commit+0x13 #5 0xffffffff81e4c2e8 at drm_client_modeset_commit_atomic+0x148 #6 0xffffffff81e4c046 at drm_client_modeset_commit_force+0x66 #7 0xffffffff81e8bf1a at drm_fb_helper_restore_fbdev_mode_unlocked+0x7a #8 0xffffffff81e85ef6 at vt_kms_postswitch+0x166 #9 0xffffffff807a59f0 at vt_window_switch+0x120 #10 0xffffffff807a2b4f at vtterm_cngrab+0x4f #11 0xffffffff80865716 at cngrab+0x16 #12 0xffffffff808cbe1c at vpanic+0xec #13 0xffffffff808cbd23 at panic+0x43 #14 0xffffffff80ca928c at trap_fatal+0x2dc #15 0xffffffff80ca962f at trap_pfault+0x32f #16 0xffffffff80ca8a3c at trap+0x23c #17 0xffffffff80c81fc8 at calltrap+0x8 WARNING !drm_modeset_is_locked(&plane->mutex) failed at /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:871 #0 0xffffffff81ec2c63 at linux_dump_stack+0x23 #1 0xffffffff81e4160f at drm_atomic_helper_check_planes+0xaf #2 0xffffffff81d39847 at intel_atomic_check+0x11c7 #3 0xffffffff81e3f383 at drm_atomic_check_only+0x423 #4 0xffffffff81e3f783 at drm_atomic_commit+0x13 #5 0xffffffff81e4c2e8 at drm_client_modeset_commit_atomic+0x148 #6 0xffffffff81e4c046 at drm_client_modeset_commit_force+0x66 #7 0xffffffff81e8bf1a at drm_fb_helper_restore_fbdev_mode_unlocked+0x7a #8 0xffffffff81e85ef6 at vt_kms_postswitch+0x166 #9 0xffffffff807a59f0 at vt_window_switch+0x120 #10 0xffffffff807a2b4f at vtterm_cngrab+0x4f #11 0xffffffff80865716 at cngrab+0x16 #12 0xffffffff808cbe1c at vpanic+0xec #13 0xffffffff808cbd23 at panic+0x43 #14 0xffffffff80ca928c at trap_fatal+0x2dc #15 0xffffffff80ca962f at trap_pfault+0x32f #16 0xffffffff80ca8a3c at trap+0x23c #17 0xffffffff80c81fc8 at calltrap+0x8 WARNING !drm_modeset_is_locked(&plane->mutex) failed at /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:871 #0 0xffffffff81ec2c63 at linux_dump_stack+0x23 #1 0xffffffff81e4160f at drm_atomic_helper_check_planes+0xaf #2 0xffffffff81d39847 at intel_atomic_check+0x11c7 #3 0xffffffff81e3f383 at drm_atomic_check_only+0x423 #4 0xffffffff81e3f783 at drm_atomic_commit+0x13 #5 0xffffffff81e4c2e8 at drm_client_modeset_commit_atomic+0x148 #6 0xffffffff81e4c046 at drm_client_modeset_commit_force+0x66 #7 0xffffffff81e8bf1a at drm_fb_helper_restore_fbdev_mode_unlocked+0x7a #8 0xffffffff81e85ef6 at vt_kms_postswitch+0x166 #9 0xffffffff807a59f0 at vt_window_switch+0x120 #10 0xffffffff807a2b4f at vtterm_cngrab+0x4f #11 0xffffffff80865716 at cngrab+0x16 #12 0xffffffff808cbe1c at vpanic+0xec #13 0xffffffff808cbd23 at panic+0x43 #14 0xffffffff80ca928c at trap_fatal+0x2dc #15 0xffffffff80ca962f at trap_pfault+0x32f #16 0xffffffff80ca8a3c at trap+0x23c #17 0xffffffff80c81fc8 at calltrap+0x8 WARNING !drm_modeset_is_locked(&plane->mutex) failed at /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:871 #0 0xffffffff81ec2c63 at linux_dump_stack+0x23 #1 0xffffffff81e4160f at drm_atomic_helper_check_planes+0xaf #2 0xffffffff81d39847 at intel_atomic_check+0x11c7 #3 0xffffffff81e3f383 at drm_atomic_check_only+0x423 #4 0xffffffff81e3f783 at drm_atomic_commit+0x13 #5 0xffffffff81e4c2e8 at drm_client_modeset_commit_atomic+0x148 #6 0xffffffff81e4c046 at drm_client_modeset_commit_force+0x66 #7 0xffffffff81e8bf1a at drm_fb_helper_restore_fbdev_mode_unlocked+0x7a #8 0xffffffff81e85ef6 at vt_kms_postswitch+0x166 #9 0xffffffff807a59f0 at vt_window_switch+0x120 #10 0xffffffff807a2b4f at vtterm_cngrab+0x4f #11 0xffffffff80865716 at cngrab+0x16 #12 0xffffffff808cbe1c at vpanic+0xec #13 0xffffffff808cbd23 at panic+0x43 #14 0xffffffff80ca928c at trap_fatal+0x2dc #15 0xffffffff80ca962f at trap_pfault+0x32f #16 0xffffffff80ca8a3c at trap+0x23c #17 0xffffffff80c81fc8 at calltrap+0x8 WARN_ON(!mutex_is_locked(&dev->struct_mutex)) WARN_ON(!mutex_is_locked(&fbc->lock))WARN_ON(!mutex_is_locked(&fbc->lock))WARN_ON(!mutex_is_locked(&fbc->lock)) panic: page fault cpuid = 0 time = 1635862018 WARNING !drm_modeset_is_locked(&crtc->mutex) failed at /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:621 #0 0xffffffff81ec2c63 at linux_dump_stack+0x23 #1 0xffffffff81e403b2 at drm_atomic_helper_check_modeset+0xb2 #2 0xffffffff81d3870c at intel_atomic_check+0x8c #3 0xffffffff81e3f383 at drm_atomic_check_only+0x423 #4 0xffffffff81e3f783 at drm_atomic_commit+0x13 #5 0xffffffff81e4c2e8 at drm_client_modeset_commit_atomic+0x148 #6 0xffffffff81e4c046 at drm_client_modeset_commit_force+0x66 #7 0xffffffff81e8bf1a at drm_fb_helper_restore_fbdev_mode_unlocked+0x7a #8 0xffffffff81e85ef6 at vt_kms_postswitch+0x166 #9 0xffffffff807a5ba9 at vt_window_switch+0x2d9 #10 0xffffffff808cb7ec at kern_reboot+0x17c #11 0xffffffff808cbecb at vpanic+0x19b #12 0xffffffff808cbd23 at panic+0x43 #13 0xffffffff80ca928c at trap_fatal+0x2dc #14 0xffffffff80ca962f at trap_pfault+0x32f #15 0xffffffff80ca8a3c at trap+0x23c #16 0xffffffff80c81fc8 at calltrap+0x8 #17 0xffffffff808b4d69 at sysctl_kern_proc_pathname+0xc9 WARNING !drm_modeset_is_locked(&crtc->mutex) failed at /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:621 #0 0xffffffff81ec2c63 at linux_dump_stack+0x23 #1 0xffffffff81e403b2 at drm_atomic_helper_check_modeset+0xb2 #2 0xffffffff81d3870c at intel_atomic_check+0x8c #3 0xffffffff81e3f383 at drm_atomic_check_only+0x423 #4 0xffffffff81e3f783 at drm_atomic_commit+0x13 #5 0xffffffff81e4c2e8 at drm_client_modeset_commit_atomic+0x148 #6 0xffffffff81e4c046 at drm_client_modeset_commit_force+0x66 #7 0xffffffff81e8bf1a at drm_fb_helper_restore_fbdev_mode_unlocked+0x7a #8 0xffffffff81e85ef6 at vt_kms_postswitch+0x166 #9 0xffffffff807a5ba9 at vt_window_switch+0x2d9 #10 0xffffffff808cb7ec at kern_reboot+0x17c #11 0xffffffff808cbecb at vpanic+0x19b #12 0xffffffff808cbd23 at panic+0x43 #13 0xffffffff80ca928c at trap_fatal+0x2dc #14 0xffffffff80ca962f at trap_pfault+0x32f #15 0xffffffff80ca8a3c at trap+0x23c #16 0xffffffff80c81fc8 at calltrap+0x8 #17 0xffffffff808b4d69 at sysctl_kern_proc_pathname+0xc9 WARNING !drm_modeset_is_locked(&crtc->mutex) failed at /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:621 #0 0xffffffff81ec2c63 at linux_dump_stack+0x23 #1 0xffffffff81e403b2 at drm_atomic_helper_check_modeset+0xb2 #2 0xffffffff81d3870c at intel_atomic_check+0x8c #3 0xffffffff81e3f383 at drm_atomic_check_only+0x423 #4 0xffffffff81e3f783 at drm_atomic_commit+0x13 #5 0xffffffff81e4c2e8 at drm_client_modeset_commit_atomic+0x148 #6 0xffffffff81e4c046 at drm_client_modeset_commit_force+0x66 #7 0xffffffff81e8bf1a at drm_fb_helper_restore_fbdev_mode_unlocked+0x7a #8 0xffffffff81e85ef6 at vt_kms_postswitch+0x166 #9 0xffffffff807a5ba9 at vt_window_switch+0x2d9 #10 0xffffffff808cb7ec at kern_reboot+0x17c #11 0xffffffff808cbecb at vpanic+0x19b #12 0xffffffff808cbd23 at panic+0x43 #13 0xffffffff80ca928c at trap_fatal+0x2dc #14 0xffffffff80ca962f at trap_pfault+0x32f #15 0xffffffff80ca8a3c at trap+0x23c #16 0xffffffff80c81fc8 at calltrap+0x8 #17 0xffffffff808b4d69 at sysctl_kern_proc_pathname+0xc9 WARNING !drm_modeset_is_locked(&dev->mode_config.connection_mutex) failed at /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:666 #0 0xffffffff81ec2c63 at linux_dump_stack+0x23 #1 0xffffffff81e40542 at drm_atomic_helper_check_modeset+0x242 #2 0xffffffff81d3870c at intel_atomic_check+0x8c #3 0xffffffff81e3f383 at drm_atomic_check_only+0x423 #4 0xffffffff81e3f783 at drm_atomic_commit+0x13 #5 0xffffffff81e4c2e8 at drm_client_modeset_commit_atomic+0x148 #6 0xffffffff81e4c046 at drm_client_modeset_commit_force+0x66 #7 0xffffffff81e8bf1a at drm_fb_helper_restore_fbdev_mode_unlocked+0x7a #8 0xffffffff81e85ef6 at vt_kms_postswitch+0x166 #9 0xffffffff807a5ba9 at vt_window_switch+0x2d9 #10 0xffffffff808cb7ec at kern_reboot+0x17c #11 0xffffffff808cbecb at vpanic+0x19b #12 0xffffffff808cbd23 at panic+0x43 #13 0xffffffff80ca928c at trap_fatal+0x2dc #14 0xffffffff80ca962f at trap_pfault+0x32f #15 0xffffffff80ca8a3c at trap+0x23c #16 0xffffffff80c81fc8 at calltrap+0x8 #17 0xffffffff808b4d69 at sysctl_kern_proc_pathname+0xc9 WARNING !drm_modeset_is_locked(&plane->mutex) failed at /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:871 #0 0xffffffff81ec2c63 at linux_dump_stack+0x23 #1 0xffffffff81e4160f at drm_atomic_helper_check_planes+0xaf #2 0xffffffff81d39847 at intel_atomic_check+0x11c7 #3 0xffffffff81e3f383 at drm_atomic_check_only+0x423 #4 0xffffffff81e3f783 at drm_atomic_commit+0x13 #5 0xffffffff81e4c2e8 at drm_client_modeset_commit_atomic+0x148 #6 0xffffffff81e4c046 at drm_client_modeset_commit_force+0x66 #7 0xffffffff81e8bf1a at drm_fb_helper_restore_fbdev_mode_unlocked+0x7a #8 0xffffffff81e85ef6 at vt_kms_postswitch+0x166 #9 0xffffffff807a5ba9 at vt_window_switch+0x2d9 #10 0xffffffff808cb7ec at kern_reboot+0x17c #11 0xffffffff808cbecb at vpanic+0x19b #12 0xffffffff808cbd23 at panic+0x43 #13 0xffffffff80ca928c at trap_fatal+0x2dc #14 0xffffffff80ca962f at trap_pfault+0x32f #15 0xffffffff80ca8a3c at trap+0x23c #16 0xffffffff80c81fc8 at calltrap+0x8 #17 0xffffffff808b4d69 at sysctl_kern_proc_pathname+0xc9 WARNING !drm_modeset_is_locked(&plane->mutex) failed at /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:871 #0 0xffffffff81ec2c63 at linux_dump_stack+0x23 #1 0xffffffff81e4160f at drm_atomic_helper_check_planes+0xaf #2 0xffffffff81d39847 at intel_atomic_check+0x11c7 #3 0xffffffff81e3f383 at drm_atomic_check_only+0x423 #4 0xffffffff81e3f783 at drm_atomic_commit+0x13 #5 0xffffffff81e4c2e8 at drm_client_modeset_commit_atomic+0x148 #6 0xffffffff81e4c046 at drm_client_modeset_commit_force+0x66 #7 0xffffffff81e8bf1a at drm_fb_helper_restore_fbdev_mode_unlocked+0x7a #8 0xffffffff81e85ef6 at vt_kms_postswitch+0x166 #9 0xffffffff807a5ba9 at vt_window_switch+0x2d9 #10 0xffffffff808cb7ec at kern_reboot+0x17c #11 0xffffffff808cbecb at vpanic+0x19b #12 0xffffffff808cbd23 at panic+0x43 #13 0xffffffff80ca928c at trap_fatal+0x2dc #14 0xffffffff80ca962f at trap_pfault+0x32f #15 0xffffffff80ca8a3c at trap+0x23c #16 0xffffffff80c81fc8 at calltrap+0x8 #17 0xffffffff808b4d69 at sysctl_kern_proc_pathname+0xc9 WARNING !drm_modeset_is_locked(&plane->mutex) failed at /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:871 #0 0xffffffff81ec2c63 at linux_dump_stack+0x23 #1 0xffffffff81e4160f at drm_atomic_helper_check_planes+0xaf #2 0xffffffff81d39847 at intel_atomic_check+0x11c7 #3 0xffffffff81e3f383 at drm_atomic_check_only+0x423 #4 0xffffffff81e3f783 at drm_atomic_commit+0x13 #5 0xffffffff81e4c2e8 at drm_client_modeset_commit_atomic+0x148 #6 0xffffffff81e4c046 at drm_client_modeset_commit_force+0x66 #7 0xffffffff81e8bf1a at drm_fb_helper_restore_fbdev_mode_unlocked+0x7a #8 0xffffffff81e85ef6 at vt_kms_postswitch+0x166 #9 0xffffffff807a5ba9 at vt_window_switch+0x2d9 #10 0xffffffff808cb7ec at kern_reboot+0x17c #11 0xffffffff808cbecb at vpanic+0x19b #12 0xffffffff808cbd23 at panic+0x43 #13 0xffffffff80ca928c at trap_fatal+0x2dc #14 0xffffffff80ca962f at trap_pfault+0x32f #15 0xffffffff80ca8a3c at trap+0x23c #16 0xffffffff80c81fc8 at calltrap+0x8 #17 0xffffffff808b4d69 at sysctl_kern_proc_pathname+0xc9 WARNING !drm_modeset_is_locked(&plane->mutex) failed at /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:871 #0 0xffffffff81ec2c63 at linux_dump_stack+0x23 #1 0xffffffff81e4160f at drm_atomic_helper_check_planes+0xaf #2 0xffffffff81d39847 at intel_atomic_check+0x11c7 #3 0xffffffff81e3f383 at drm_atomic_check_only+0x423 #4 0xffffffff81e3f783 at drm_atomic_commit+0x13 #5 0xffffffff81e4c2e8 at drm_client_modeset_commit_atomic+0x148 #6 0xffffffff81e4c046 at drm_client_modeset_commit_force+0x66 #7 0xffffffff81e8bf1a at drm_fb_helper_restore_fbdev_mode_unlocked+0x7a #8 0xffffffff81e85ef6 at vt_kms_postswitch+0x166 #9 0xffffffff807a5ba9 at vt_window_switch+0x2d9 #10 0xffffffff808cb7ec at kern_reboot+0x17c #11 0xffffffff808cbecb at vpanic+0x19b #12 0xffffffff808cbd23 at panic+0x43 #13 0xffffffff80ca928c at trap_fatal+0x2dc #14 0xffffffff80ca962f at trap_pfault+0x32f #15 0xffffffff80ca8a3c at trap+0x23c #16 0xffffffff80c81fc8 at calltrap+0x8 #17 0xffffffff808b4d69 at sysctl_kern_proc_pathname+0xc9 WARNING !drm_modeset_is_locked(&plane->mutex) failed at /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:871 #0 0xffffffff81ec2c63 at linux_dump_stack+0x23 #1 0xffffffff81e4160f at drm_atomic_helper_check_planes+0xaf #2 0xffffffff81d39847 at intel_atomic_check+0x11c7 #3 0xffffffff81e3f383 at drm_atomic_check_only+0x423 #4 0xffffffff81e3f783 at drm_atomic_commit+0x13 #5 0xffffffff81e4c2e8 at drm_client_modeset_commit_atomic+0x148 #6 0xffffffff81e4c046 at drm_client_modeset_commit_force+0x66 #7 0xffffffff81e8bf1a at drm_fb_helper_restore_fbdev_mode_unlocked+0x7a #8 0xffffffff81e85ef6 at vt_kms_postswitch+0x166 #9 0xffffffff807a5ba9 at vt_window_switch+0x2d9 #10 0xffffffff808cb7ec at kern_reboot+0x17c #11 0xffffffff808cbecb at vpanic+0x19b #12 0xffffffff808cbd23 at panic+0x43 #13 0xffffffff80ca928c at trap_fatal+0x2dc #14 0xffffffff80ca962f at trap_pfault+0x32f #15 0xffffffff80ca8a3c at trap+0x23c #16 0xffffffff80c81fc8 at calltrap+0x8 #17 0xffffffff808b4d69 at sysctl_kern_proc_pathname+0xc9 WARNING !drm_modeset_is_locked(&plane->mutex) failed at /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:871 #0 0xffffffff81ec2c63 at linux_dump_stack+0x23 #1 0xffffffff81e4160f at drm_atomic_helper_check_planes+0xaf #2 0xffffffff81d39847 at intel_atomic_check+0x11c7 #3 0xffffffff81e3f383 at drm_atomic_check_only+0x423 #4 0xffffffff81e3f783 at drm_atomic_commit+0x13 #5 0xffffffff81e4c2e8 at drm_client_modeset_commit_atomic+0x148 #6 0xffffffff81e4c046 at drm_client_modeset_commit_force+0x66 #7 0xffffffff81e8bf1a at drm_fb_helper_restore_fbdev_mode_unlocked+0x7a #8 0xffffffff81e85ef6 at vt_kms_postswitch+0x166 #9 0xffffffff807a5ba9 at vt_window_switch+0x2d9 #10 0xffffffff808cb7ec at kern_reboot+0x17c #11 0xffffffff808cbecb at vpanic+0x19b #12 0xffffffff808cbd23 at panic+0x43 #13 0xffffffff80ca928c at trap_fatal+0x2dc #14 0xffffffff80ca962f at trap_pfault+0x32f #15 0xffffffff80ca8a3c at trap+0x23c #16 0xffffffff80c81fc8 at calltrap+0x8 #17 0xffffffff808b4d69 at sysctl_kern_proc_pathname+0xc9 WARNING !drm_modeset_is_locked(&plane->mutex) failed at /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:871 #0 0xffffffff81ec2c63 at linux_dump_stack+0x23 #1 0xffffffff81e4160f at drm_atomic_helper_check_planes+0xaf #2 0xffffffff81d39847 at intel_atomic_check+0x11c7 #3 0xffffffff81e3f383 at drm_atomic_check_only+0x423 #4 0xffffffff81e3f783 at drm_atomic_commit+0x13 #5 0xffffffff81e4c2e8 at drm_client_modeset_commit_atomic+0x148 #6 0xffffffff81e4c046 at drm_client_modeset_commit_force+0x66 #7 0xffffffff81e8bf1a at drm_fb_helper_restore_fbdev_mode_unlocked+0x7a #8 0xffffffff81e85ef6 at vt_kms_postswitch+0x166 #9 0xffffffff807a5ba9 at vt_window_switch+0x2d9 #10 0xffffffff808cb7ec at kern_reboot+0x17c #11 0xffffffff808cbecb at vpanic+0x19b #12 0xffffffff808cbd23 at panic+0x43 #13 0xffffffff80ca928c at trap_fatal+0x2dc #14 0xffffffff80ca962f at trap_pfault+0x32f #15 0xffffffff80ca8a3c at trap+0x23c #16 0xffffffff80c81fc8 at calltrap+0x8 #17 0xffffffff808b4d69 at sysctl_kern_proc_pathname+0xc9 WARNING !drm_modeset_is_locked(&plane->mutex) failed at /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:871 #0 0xffffffff81ec2c63 at linux_dump_stack+0x23 #1 0xffffffff81e4160f at drm_atomic_helper_check_planes+0xaf #2 0xffffffff81d39847 at intel_atomic_check+0x11c7 #3 0xffffffff81e3f383 at drm_atomic_check_only+0x423 #4 0xffffffff81e3f783 at drm_atomic_commit+0x13 #5 0xffffffff81e4c2e8 at drm_client_modeset_commit_atomic+0x148 #6 0xffffffff81e4c046 at drm_client_modeset_commit_force+0x66 #7 0xffffffff81e8bf1a at drm_fb_helper_restore_fbdev_mode_unlocked+0x7a #8 0xffffffff81e85ef6 at vt_kms_postswitch+0x166 #9 0xffffffff807a5ba9 at vt_window_switch+0x2d9 #10 0xffffffff808cb7ec at kern_reboot+0x17c #11 0xffffffff808cbecb at vpanic+0x19b #12 0xffffffff808cbd23 at panic+0x43 #13 0xffffffff80ca928c at trap_fatal+0x2dc #14 0xffffffff80ca962f at trap_pfault+0x32f #15 0xffffffff80ca8a3c at trap+0x23c #16 0xffffffff80c81fc8 at calltrap+0x8 #17 0xffffffff808b4d69 at sysctl_kern_proc_pathname+0xc9 WARNING !drm_modeset_is_locked(&plane->mutex) failed at /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:871 #0 0xffffffff81ec2c63 at linux_dump_stack+0x23 #1 0xffffffff81e4160f at drm_atomic_helper_check_planes+0xaf #2 0xffffffff81d39847 at intel_atomic_check+0x11c7 #3 0xffffffff81e3f383 at drm_atomic_check_only+0x423 #4 0xffffffff81e3f783 at drm_atomic_commit+0x13 #5 0xffffffff81e4c2e8 at drm_client_modeset_commit_atomic+0x148 #6 0xffffffff81e4c046 at drm_client_modeset_commit_force+0x66 #7 0xffffffff81e8bf1a at drm_fb_helper_restore_fbdev_mode_unlocked+0x7a #8 0xffffffff81e85ef6 at vt_kms_postswitch+0x166 #9 0xffffffff807a5ba9 at vt_window_switch+0x2d9 #10 0xffffffff808cb7ec at kern_reboot+0x17c #11 0xffffffff808cbecb at vpanic+0x19b #12 0xffffffff808cbd23 at panic+0x43 #13 0xffffffff80ca928c at trap_fatal+0x2dc #14 0xffffffff80ca962f at trap_pfault+0x32f #15 0xffffffff80ca8a3c at trap+0x23c #16 0xffffffff80c81fc8 at calltrap+0x8 #17 0xffffffff808b4d69 at sysctl_kern_proc_pathname+0xc9 WARN_ON(!mutex_is_locked(&dev->struct_mutex)) WARN_ON(!mutex_is_locked(&fbc->lock))WARN_ON(!mutex_is_locked(&fbc->lock))WARN_ON(!mutex_is_locked(&fbc->lock)) Uptime: 1m6s WARNING !drm_modeset_is_locked(&crtc->mutex) failed at /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:621 #0 0xffffffff81ec2c63 at linux_dump_stack+0x23 #1 0xffffffff81e403b2 at drm_atomic_helper_check_modeset+0xb2 #2 0xffffffff81d3870c at intel_atomic_check+0x8c #3 0xffffffff81e3f383 at drm_atomic_check_only+0x423 #4 0xffffffff81e3f783 at drm_atomic_commit+0x13 #5 0xffffffff81e4c2e8 at drm_client_modeset_commit_atomic+0x148 #6 0xffffffff81e4c046 at drm_client_modeset_commit_force+0x66 #7 0xffffffff81e8bf1a at drm_fb_helper_restore_fbdev_mode_unlocked+0x7a #8 0xffffffff81e85ef6 at vt_kms_postswitch+0x166 #9 0xffffffff807a5ba9 at vt_window_switch+0x2d9 #10 0xffffffff807a2b4f at vtterm_cngrab+0x4f #11 0xffffffff80865716 at cngrab+0x16 #12 0xffffffff808cb9c1 at kern_reboot+0x351 #13 0xffffffff808cbecb at vpanic+0x19b #14 0xffffffff808cbd23 at panic+0x43 #15 0xffffffff80ca928c at trap_fatal+0x2dc #16 0xffffffff80ca962f at trap_pfault+0x32f #17 0xffffffff80ca8a3c at trap+0x23c WARNING !drm_modeset_is_locked(&crtc->mutex) failed at /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:621 #0 0xffffffff81ec2c63 at linux_dump_stack+0x23 #1 0xffffffff81e403b2 at drm_atomic_helper_check_modeset+0xb2 #2 0xffffffff81d3870c at intel_atomic_check+0x8c #3 0xffffffff81e3f383 at drm_atomic_check_only+0x423 #4 0xffffffff81e3f783 at drm_atomic_commit+0x13 #5 0xffffffff81e4c2e8 at drm_client_modeset_commit_atomic+0x148 #6 0xffffffff81e4c046 at drm_client_modeset_commit_force+0x66 #7 0xffffffff81e8bf1a at drm_fb_helper_restore_fbdev_mode_unlocked+0x7a #8 0xffffffff81e85ef6 at vt_kms_postswitch+0x166 #9 0xffffffff807a5ba9 at vt_window_switch+0x2d9 #10 0xffffffff807a2b4f at vtterm_cngrab+0x4f #11 0xffffffff80865716 at cngrab+0x16 #12 0xffffffff808cb9c1 at kern_reboot+0x351 #13 0xffffffff808cbecb at vpanic+0x19b #14 0xffffffff808cbd23 at panic+0x43 #15 0xffffffff80ca928c at trap_fatal+0x2dc #16 0xffffffff80ca962f at trap_pfault+0x32f #17 0xffffffff80ca8a3c at trap+0x23c WARNING !drm_modeset_is_locked(&crtc->mutex) failed at /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:621 #0 0xffffffff81ec2c63 at linux_dump_stack+0x23 #1 0xffffffff81e403b2 at drm_atomic_helper_check_modeset+0xb2 #2 0xffffffff81d3870c at intel_atomic_check+0x8c #3 0xffffffff81e3f383 at drm_atomic_check_only+0x423 #4 0xffffffff81e3f783 at drm_atomic_commit+0x13 #5 0xffffffff81e4c2e8 at drm_client_modeset_commit_atomic+0x148 #6 0xffffffff81e4c046 at drm_client_modeset_commit_force+0x66 #7 0xffffffff81e8bf1a at drm_fb_helper_restore_fbdev_mode_unlocked+0x7a #8 0xffffffff81e85ef6 at vt_kms_postswitch+0x166 #9 0xffffffff807a5ba9 at vt_window_switch+0x2d9 #10 0xffffffff807a2b4f at vtterm_cngrab+0x4f #11 0xffffffff80865716 at cngrab+0x16 #12 0xffffffff808cb9c1 at kern_reboot+0x351 #13 0xffffffff808cbecb at vpanic+0x19b #14 0xffffffff808cbd23 at panic+0x43 #15 0xffffffff80ca928c at trap_fatal+0x2dc #16 0xffffffff80ca962f at trap_pfault+0x32f #17 0xffffffff80ca8a3c at trap+0x23c WARNING !drm_modeset_is_locked(&dev->mode_config.connection_mutex) failed at /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:666 #0 0xffffffff81ec2c63 at linux_dump_stack+0x23 #1 0xffffffff81e40542 at drm_atomic_helper_check_modeset+0x242 #2 0xffffffff81d3870c at intel_atomic_check+0x8c #3 0xffffffff81e3f383 at drm_atomic_check_only+0x423 #4 0xffffffff81e3f783 at drm_atomic_commit+0x13 #5 0xffffffff81e4c2e8 at drm_client_modeset_commit_atomic+0x148 #6 0xffffffff81e4c046 at drm_client_modeset_commit_force+0x66 #7 0xffffffff81e8bf1a at drm_fb_helper_restore_fbdev_mode_unlocked+0x7a #8 0xffffffff81e85ef6 at vt_kms_postswitch+0x166 #9 0xffffffff807a5ba9 at vt_window_switch+0x2d9 #10 0xffffffff807a2b4f at vtterm_cngrab+0x4f #11 0xffffffff80865716 at cngrab+0x16 #12 0xffffffff808cb9c1 at kern_reboot+0x351 #13 0xffffffff808cbecb at vpanic+0x19b #14 0xffffffff808cbd23 at panic+0x43 #15 0xffffffff80ca928c at trap_fatal+0x2dc #16 0xffffffff80ca962f at trap_pfault+0x32f #17 0xffffffff80ca8a3c at trap+0x23c WARNING !drm_modeset_is_locked(&plane->mutex) failed at /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:871 #0 0xffffffff81ec2c63 at linux_dump_stack+0x23 #1 0xffffffff81e4160f at drm_atomic_helper_check_planes+0xaf #2 0xffffffff81d39847 at intel_atomic_check+0x11c7 #3 0xffffffff81e3f383 at drm_atomic_check_only+0x423 #4 0xffffffff81e3f783 at drm_atomic_commit+0x13 #5 0xffffffff81e4c2e8 at drm_client_modeset_commit_atomic+0x148 #6 0xffffffff81e4c046 at drm_client_modeset_commit_force+0x66 #7 0xffffffff81e8bf1a at drm_fb_helper_restore_fbdev_mode_unlocked+0x7a #8 0xffffffff81e85ef6 at vt_kms_postswitch+0x166 #9 0xffffffff807a5ba9 at vt_window_switch+0x2d9 #10 0xffffffff807a2b4f at vtterm_cngrab+0x4f #11 0xffffffff80865716 at cngrab+0x16 #12 0xffffffff808cb9c1 at kern_reboot+0x351 #13 0xffffffff808cbecb at vpanic+0x19b #14 0xffffffff808cbd23 at panic+0x43 #15 0xffffffff80ca928c at trap_fatal+0x2dc #16 0xffffffff80ca962f at trap_pfault+0x32f #17 0xffffffff80ca8a3c at trap+0x23c WARNING !drm_modeset_is_locked(&plane->mutex) failed at /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:871 #0 0xffffffff81ec2c63 at linux_dump_stack+0x23 #1 0xffffffff81e4160f at drm_atomic_helper_check_planes+0xaf #2 0xffffffff81d39847 at intel_atomic_check+0x11c7 #3 0xffffffff81e3f383 at drm_atomic_check_only+0x423 #4 0xffffffff81e3f783 at drm_atomic_commit+0x13 #5 0xffffffff81e4c2e8 at drm_client_modeset_commit_atomic+0x148 #6 0xffffffff81e4c046 at drm_client_modeset_commit_force+0x66 #7 0xffffffff81e8bf1a at drm_fb_helper_restore_fbdev_mode_unlocked+0x7a #8 0xffffffff81e85ef6 at vt_kms_postswitch+0x166 #9 0xffffffff807a5ba9 at vt_window_switch+0x2d9 #10 0xffffffff807a2b4f at vtterm_cngrab+0x4f #11 0xffffffff80865716 at cngrab+0x16 #12 0xffffffff808cb9c1 at kern_reboot+0x351 #13 0xffffffff808cbecb at vpanic+0x19b #14 0xffffffff808cbd23 at panic+0x43 #15 0xffffffff80ca928c at trap_fatal+0x2dc #16 0xffffffff80ca962f at trap_pfault+0x32f #17 0xffffffff80ca8a3c at trap+0x23c WARNING !drm_modeset_is_locked(&plane->mutex) failed at /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:871 #0 0xffffffff81ec2c63 at linux_dump_stack+0x23 #1 0xffffffff81e4160f at drm_atomic_helper_check_planes+0xaf #2 0xffffffff81d39847 at intel_atomic_check+0x11c7 #3 0xffffffff81e3f383 at drm_atomic_check_only+0x423 #4 0xffffffff81e3f783 at drm_atomic_commit+0x13 #5 0xffffffff81e4c2e8 at drm_client_modeset_commit_atomic+0x148 #6 0xffffffff81e4c046 at drm_client_modeset_commit_force+0x66 #7 0xffffffff81e8bf1a at drm_fb_helper_restore_fbdev_mode_unlocked+0x7a #8 0xffffffff81e85ef6 at vt_kms_postswitch+0x166 #9 0xffffffff807a5ba9 at vt_window_switch+0x2d9 #10 0xffffffff807a2b4f at vtterm_cngrab+0x4f #11 0xffffffff80865716 at cngrab+0x16 #12 0xffffffff808cb9c1 at kern_reboot+0x351 #13 0xffffffff808cbecb at vpanic+0x19b #14 0xffffffff808cbd23 at panic+0x43 #15 0xffffffff80ca928c at trap_fatal+0x2dc #16 0xffffffff80ca962f at trap_pfault+0x32f #17 0xffffffff80ca8a3c at trap+0x23c WARNING !drm_modeset_is_locked(&plane->mutex) failed at /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:871 #0 0xffffffff81ec2c63 at linux_dump_stack+0x23 #1 0xffffffff81e4160f at drm_atomic_helper_check_planes+0xaf #2 0xffffffff81d39847 at intel_atomic_check+0x11c7 #3 0xffffffff81e3f383 at drm_atomic_check_only+0x423 #4 0xffffffff81e3f783 at drm_atomic_commit+0x13 #5 0xffffffff81e4c2e8 at drm_client_modeset_commit_atomic+0x148 #6 0xffffffff81e4c046 at drm_client_modeset_commit_force+0x66 #7 0xffffffff81e8bf1a at drm_fb_helper_restore_fbdev_mode_unlocked+0x7a #8 0xffffffff81e85ef6 at vt_kms_postswitch+0x166 #9 0xffffffff807a5ba9 at vt_window_switch+0x2d9 #10 0xffffffff807a2b4f at vtterm_cngrab+0x4f #11 0xffffffff80865716 at cngrab+0x16 #12 0xffffffff808cb9c1 at kern_reboot+0x351 #13 0xffffffff808cbecb at vpanic+0x19b #14 0xffffffff808cbd23 at panic+0x43 #15 0xffffffff80ca928c at trap_fatal+0x2dc #16 0xffffffff80ca962f at trap_pfault+0x32f #17 0xffffffff80ca8a3c at trap+0x23c WARNING !drm_modeset_is_locked(&plane->mutex) failed at /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:871 #0 0xffffffff81ec2c63 at linux_dump_stack+0x23 #1 0xffffffff81e4160f at drm_atomic_helper_check_planes+0xaf #2 0xffffffff81d39847 at intel_atomic_check+0x11c7 #3 0xffffffff81e3f383 at drm_atomic_check_only+0x423 #4 0xffffffff81e3f783 at drm_atomic_commit+0x13 #5 0xffffffff81e4c2e8 at drm_client_modeset_commit_atomic+0x148 #6 0xffffffff81e4c046 at drm_client_modeset_commit_force+0x66 #7 0xffffffff81e8bf1a at drm_fb_helper_restore_fbdev_mode_unlocked+0x7a #8 0xffffffff81e85ef6 at vt_kms_postswitch+0x166 #9 0xffffffff807a5ba9 at vt_window_switch+0x2d9 #10 0xffffffff807a2b4f at vtterm_cngrab+0x4f #11 0xffffffff80865716 at cngrab+0x16 #12 0xffffffff808cb9c1 at kern_reboot+0x351 #13 0xffffffff808cbecb at vpanic+0x19b #14 0xffffffff808cbd23 at panic+0x43 #15 0xffffffff80ca928c at trap_fatal+0x2dc #16 0xffffffff80ca962f at trap_pfault+0x32f #17 0xffffffff80ca8a3c at trap+0x23c WARNING !drm_modeset_is_locked(&plane->mutex) failed at /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:871 #0 0xffffffff81ec2c63 at linux_dump_stack+0x23 #1 0xffffffff81e4160f at drm_atomic_helper_check_planes+0xaf #2 0xffffffff81d39847 at intel_atomic_check+0x11c7 #3 0xffffffff81e3f383 at drm_atomic_check_only+0x423 #4 0xffffffff81e3f783 at drm_atomic_commit+0x13 #5 0xffffffff81e4c2e8 at drm_client_modeset_commit_atomic+0x148 #6 0xffffffff81e4c046 at drm_client_modeset_commit_force+0x66 #7 0xffffffff81e8bf1a at drm_fb_helper_restore_fbdev_mode_unlocked+0x7a #8 0xffffffff81e85ef6 at vt_kms_postswitch+0x166 #9 0xffffffff807a5ba9 at vt_window_switch+0x2d9 #10 0xffffffff807a2b4f at vtterm_cngrab+0x4f #11 0xffffffff80865716 at cngrab+0x16 #12 0xffffffff808cb9c1 at kern_reboot+0x351 #13 0xffffffff808cbecb at vpanic+0x19b #14 0xffffffff808cbd23 at panic+0x43 #15 0xffffffff80ca928c at trap_fatal+0x2dc #16 0xffffffff80ca962f at trap_pfault+0x32f #17 0xffffffff80ca8a3c at trap+0x23c WARNING !drm_modeset_is_locked(&plane->mutex) failed at /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:871 #0 0xffffffff81ec2c63 at linux_dump_stack+0x23 #1 0xffffffff81e4160f at drm_atomic_helper_check_planes+0xaf #2 0xffffffff81d39847 at intel_atomic_check+0x11c7 #3 0xffffffff81e3f383 at drm_atomic_check_only+0x423 #4 0xffffffff81e3f783 at drm_atomic_commit+0x13 #5 0xffffffff81e4c2e8 at drm_client_modeset_commit_atomic+0x148 #6 0xffffffff81e4c046 at drm_client_modeset_commit_force+0x66 #7 0xffffffff81e8bf1a at drm_fb_helper_restore_fbdev_mode_unlocked+0x7a #8 0xffffffff81e85ef6 at vt_kms_postswitch+0x166 #9 0xffffffff807a5ba9 at vt_window_switch+0x2d9 #10 0xffffffff807a2b4f at vtterm_cngrab+0x4f #11 0xffffffff80865716 at cngrab+0x16 #12 0xffffffff808cb9c1 at kern_reboot+0x351 #13 0xffffffff808cbecb at vpanic+0x19b #14 0xffffffff808cbd23 at panic+0x43 #15 0xffffffff80ca928c at trap_fatal+0x2dc #16 0xffffffff80ca962f at trap_pfault+0x32f #17 0xffffffff80ca8a3c at trap+0x23c WARNING !drm_modeset_is_locked(&plane->mutex) failed at /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:871 #0 0xffffffff81ec2c63 at linux_dump_stack+0x23 #1 0xffffffff81e4160f at drm_atomic_helper_check_planes+0xaf #2 0xffffffff81d39847 at intel_atomic_check+0x11c7 #3 0xffffffff81e3f383 at drm_atomic_check_only+0x423 #4 0xffffffff81e3f783 at drm_atomic_commit+0x13 #5 0xffffffff81e4c2e8 at drm_client_modeset_commit_atomic+0x148 #6 0xffffffff81e4c046 at drm_client_modeset_commit_force+0x66 #7 0xffffffff81e8bf1a at drm_fb_helper_restore_fbdev_mode_unlocked+0x7a #8 0xffffffff81e85ef6 at vt_kms_postswitch+0x166 #9 0xffffffff807a5ba9 at vt_window_switch+0x2d9 #10 0xffffffff807a2b4f at vtterm_cngrab+0x4f #11 0xffffffff80865716 at cngrab+0x16 #12 0xffffffff808cb9c1 at kern_reboot+0x351 #13 0xffffffff808cbecb at vpanic+0x19b #14 0xffffffff808cbd23 at panic+0x43 #15 0xffffffff80ca928c at trap_fatal+0x2dc #16 0xffffffff80ca962f at trap_pfault+0x32f #17 0xffffffff80ca8a3c at trap+0x23c WARNING !drm_modeset_is_locked(&plane->mutex) failed at /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:871 #0 0xffffffff81ec2c63 at linux_dump_stack+0x23 #1 0xffffffff81e4160f at drm_atomic_helper_check_planes+0xaf #2 0xffffffff81d39847 at intel_atomic_check+0x11c7 #3 0xffffffff81e3f383 at drm_atomic_check_only+0x423 #4 0xffffffff81e3f783 at drm_atomic_commit+0x13 #5 0xffffffff81e4c2e8 at drm_client_modeset_commit_atomic+0x148 #6 0xffffffff81e4c046 at drm_client_modeset_commit_force+0x66 #7 0xffffffff81e8bf1a at drm_fb_helper_restore_fbdev_mode_unlocked+0x7a #8 0xffffffff81e85ef6 at vt_kms_postswitch+0x166 #9 0xffffffff807a5ba9 at vt_window_switch+0x2d9 #10 0xffffffff807a2b4f at vtterm_cngrab+0x4f #11 0xffffffff80865716 at cngrab+0x16 #12 0xffffffff808cb9c1 at kern_reboot+0x351 #13 0xffffffff808cbecb at vpanic+0x19b #14 0xffffffff808cbd23 at panic+0x43 #15 0xffffffff80ca928c at trap_fatal+0x2dc #16 0xffffffff80ca962f at trap_pfault+0x32f #17 0xffffffff80ca8a3c at trap+0x23c WARN_ON(!mutex_is_locked(&dev->struct_mutex)) WARN_ON(!mutex_is_locked(&fbc->lock))WARN_ON(!mutex_is_locked(&fbc->lock))WARN_ON(!mutex_is_locked(&fbc->lock)) Dumping 811 out of 16257 MB:..2%..12%..22%..32%..42%..52%..62%..71%..81%..91% ------------------------------------------------------------------------ From nobody Tue Nov 2 15:37:53 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id B982A18290E7; Tue, 2 Nov 2021 15:38:04 +0000 (UTC) (envelope-from greg@unrelenting.technology) Received: from out10.migadu.com (out10.migadu.com [46.105.121.227]) (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 4HkDZ44LWHz3lWm; Tue, 2 Nov 2021 15:38:04 +0000 (UTC) (envelope-from greg@unrelenting.technology) Date: Tue, 02 Nov 2021 18:37:53 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=unrelenting.technology; s=key1; t=1635867477; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=DDLOhlNgmy8bMIZ7lM5duuILYqDAPWsKhCv27S8l4/c=; b=PLM5x+1HlAZ93Id1QSQykakVzXIDpX9jxp/SlUlVjzzW8jTX3cSu6fGw35suNt6Qeb+6NX RVgS5WSCMK4yoVprxi8S8jRkwC1S5ef9YYOt7eVncZKWANEmNGp+761TjRLcsZhOLNTlGK Ijnpwm8oMQTqtiNtQRJPBKPUTckE2es51HV0UZWjU14Iu2K0yG0kZxzmw2eY8ND+Yb/LHh oGZ8MTkQUcEEkL9QXvE5i2PnmPfuzTSGtGQBdXdb3ZGkvug6U379t1XREZfzC4uG7qUQRK I0RUtYvQswYfq5JNPmw9G8gEXesmbDS2ox2GYTBKiaeacO9JjpkDE3arKU1y/w== X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. To: imb@protected-networks.net, Michael Butler via freebsd-current CC: "freebsd-emulation@freebsd.org" Subject: Re: current now panics when starting VBox VM In-Reply-To: References: Message-ID: <36923A7F-23DE-490D-B1FA-A8B064740BD6@unrelenting.technology> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Migadu-Flow: FLOW_OUT X-Migadu-Auth-User: greg@unrelenting.technology X-Rspamd-Queue-Id: 4HkDZ44LWHz3lWm X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: greg@unrelenting.technology From: Greg V via freebsd-current X-Original-From: Greg V X-ThisMailContainsUnwantedMimeParts: N On November 2, 2021 5:16:35 PM GMT+03:00, Michael Butler via freebsd-curre= nt wrote: >On current as of this morning (I haven't tried to bisect yet) =2E=2E > > =2E=2E with either graphics/drm-devel-kmod or graphics/drm-current-kmod= ,=20 >trying to start a VirtualBox VM triggers this panic =2E=2E > >#16 0xffffffff80c81fc8 at calltrap+0x8 >#17 0xffffffff808b4d69 at sysctl_kern_proc_pathname+0xc9 something something https://reviews=2Efreebsd=2Eorg/D32738 ? sysctl_kern_p= roc_pathname was touched recently there=2E (Also can someone commit https://reviews=2Efreebsd=2Eorg/D30174 ? These wa= rning-filled reports are unreadable >_<) From nobody Tue Nov 2 15:55:14 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id B539218325D9; Tue, 2 Nov 2021 15:55:25 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4HkDy54DtHz3tLc; Tue, 2 Nov 2021 15:55:25 +0000 (UTC) (envelope-from hps@selasky.org) Received: from [10.36.2.165] (unknown [178.17.145.105]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 7C00B260196; Tue, 2 Nov 2021 16:55:18 +0100 (CET) Message-ID: <78914e12-b6c2-1e0c-0ba0-f690f2cc97a7@selasky.org> Date: Tue, 2 Nov 2021 16:55:14 +0100 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.2.0 Subject: Re: current now panics when starting VBox VM Content-Language: en-US To: greg@unrelenting.technology, imb@protected-networks.net, Michael Butler via freebsd-current Cc: "freebsd-emulation@freebsd.org" References: <36923A7F-23DE-490D-B1FA-A8B064740BD6@unrelenting.technology> From: Hans Petter Selasky In-Reply-To: <36923A7F-23DE-490D-B1FA-A8B064740BD6@unrelenting.technology> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4HkDy54DtHz3tLc X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: N On 11/2/21 16:37, Greg V via freebsd-current wrote: > > > On November 2, 2021 5:16:35 PM GMT+03:00, Michael Butler via freebsd-current wrote: >> On current as of this morning (I haven't tried to bisect yet) .. >> >> .. with either graphics/drm-devel-kmod or graphics/drm-current-kmod, >> trying to start a VirtualBox VM triggers this panic .. >> > >> #16 0xffffffff80c81fc8 at calltrap+0x8 >> #17 0xffffffff808b4d69 at sysctl_kern_proc_pathname+0xc9 > > something something https://reviews.freebsd.org/D32738 ? sysctl_kern_proc_pathname was touched recently there. > > (Also can someone commit https://reviews.freebsd.org/D30174 ? These warning-filled reports are unreadable >_<) Done: https://cgit.freebsd.org/src/commit/?id=2390a1441effaba0e3d0f2f447f448aaf20428f1 --HPS From nobody Tue Nov 2 21:48:40 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 87E5C1845C20; Tue, 2 Nov 2021 21:48:46 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta001.cacentral1.a.cloudfilter.net (omta001.cacentral1.a.cloudfilter.net [3.97.99.32]) (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 4HkNnp2ZqJz3rVG; Tue, 2 Nov 2021 21:48:46 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from shw-obgw-4003a.ext.cloudfilter.net ([10.228.9.183]) by cmsmtp with ESMTP id hkymmNURnczbLi1eAmhGcx; Tue, 02 Nov 2021 21:48:46 +0000 Received: from spqr.komquats.com ([70.66.148.124]) by cmsmtp with ESMTPA id i1e8mWHMrhYGxi1e9micqu; Tue, 02 Nov 2021 21:48:46 +0000 X-Authority-Analysis: v=2.4 cv=QIIL+iHL c=1 sm=1 tr=0 ts=6181b23e a=Cwc3rblV8FOMdVN/wOAqyQ==:117 a=Cwc3rblV8FOMdVN/wOAqyQ==:17 a=kj9zAlcOel0A:10 a=vIxV3rELxO4A:10 a=6I5d2MoRAAAA:8 a=YxBL1-UpAAAA:8 a=EkcXrb_YAAAA:8 a=w3lS9oWG1QiI_jSQ9-MA:9 a=CjuIK1q_8ugA:10 a=IjZwj45LgO3ly-622nXo:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=LK5xJRSDVpKd5WXXoEvA:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTPS id 328A6155; Tue, 2 Nov 2021 14:48:43 -0700 (PDT) Received: from slippy (localhost [127.0.0.1]) by slippy.cwsent.com (8.16.1/8.16.1) with ESMTP id 1A2LmeHX004930; Tue, 2 Nov 2021 14:48:41 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <202111022148.1A2LmeHX004930@slippy.cwsent.com> 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: greg@unrelenting.technology cc: imb@protected-networks.net, Michael Butler via freebsd-current , "freebsd-emulation@freebsd.org" Subject: Re: current now panics when starting VBox VM In-reply-to: <36923A7F-23DE-490D-B1FA-A8B064740BD6@unrelenting.technology> References: <36923A7F-23DE-490D-B1FA-A8B064740BD6@unrelenting.technology> Comments: In-reply-to Greg V via freebsd-current message dated "Tue, 02 Nov 2021 18:37:53 +0300." List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 02 Nov 2021 14:48:40 -0700 X-CMAE-Envelope: MS4xfBu2QizPv0BKEqYFvaUKMYnNTM/OXX+BGqapnsBwzYkmgsWz95xT5j0PPaLDCizFfZ5TA4a1BoPJ7AHj3pSZanrCT8cxEvZgfCLsDgo9A1En+dMEgmoc fBRplAN98Vd7OXdVMErXGxsyZzVFuEWADor3wFittCVQiOLesmAmKCK7+oOo7Od+ahy+Lu8ma69Aqg8sH+IIwNDnvrbnBK7lTfq7Ak+BseRjzkWQ4Jr82RXk gMta9WSpAi0jQuUpQPy82bfn33Hogk/H3FBCBc/ivtOl7RDJcZ6MUiG7z1hjH/NH58gdmEWObO0JBbFINfKzfK+RV8B7ixdZg6xFZzy5TyQ= X-Rspamd-Queue-Id: 4HkNnp2ZqJz3rVG X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N In message <36923A7F-23DE-490D-B1FA-A8B064740BD6@unrelenting.technology>, Greg V via freebsd-current writes: > > > On November 2, 2021 5:16:35 PM GMT+03:00, Michael Butler via freebsd-current > wrote: > >On current as of this morning (I haven't tried to bisect yet) .. > > > > .. with either graphics/drm-devel-kmod or graphics/drm-current-kmod, > >trying to start a VirtualBox VM triggers this panic .. > > > > >#16 0xffffffff80c81fc8 at calltrap+0x8 > >#17 0xffffffff808b4d69 at sysctl_kern_proc_pathname+0xc9 > > something something https://reviews.freebsd.org/D32738 ? sysctl_kern_proc_pat > hname was touched recently there. > > (Also can someone commit https://reviews.freebsd.org/D30174 ? These warning-f > illed reports are unreadable >_<) Usually the first thing to do with virtualbox is rebuild it. That usually fixes any panics I experience here. Of course, make sure your virtualbox ports subdirs are fully patched, as it's an opportune time to update it too. -- 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 nobody Tue Nov 2 22:32:26 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id CC61218339BB; Tue, 2 Nov 2021 22:32:32 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from mail.protected-networks.net (mail.protected-networks.net [IPv6:2001:470:8d59:1::8]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mail.protected-networks.net", Issuer "R3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HkPmJ0c6Sz4ZT1; Tue, 2 Nov 2021 22:32:32 +0000 (UTC) (envelope-from imb@protected-networks.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d= protected-networks.net; h=content-transfer-encoding:content-type :content-type:in-reply-to:from:from:references:content-language :subject:subject:user-agent:mime-version:date:date:message-id; s=201508; t=1635892346; bh=9F7W3IUSiKN1kCmZDhMDJoC4r+M67eisIXnA Ax5nE98=; b=N57G0ScY0k/WppE5tauWIjj23ywfK+IHeJ3h2xXoKZ7Tdwbt2aJt 2g6Bao+2qKjBfkO+OeKF/3Ulfs7n4x6GRH1Xi79paTQfxCy9Jbq1kxWmSHKzB3iX tEVagLH6+6Y/E0WjzaMHpTaoeoVY1XhSSAx85mITqj6E7DmAbswA5ME= Received: from [192.168.1.10] (toshi.auburn.protected-networks.net [192.168.1.10]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: imb@mail.protected-networks.net) by mail.protected-networks.net (Postfix) with ESMTPSA id B2092286DF; Tue, 2 Nov 2021 18:32:26 -0400 (EDT) Message-ID: <1ccb6ce3-2cb7-e325-79e3-cda5640f24df@protected-networks.net> Date: Tue, 2 Nov 2021 18:32:26 -0400 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Subject: Re: current now panics when starting VBox VM Content-Language: en-NZ To: Cy Schubert , greg@unrelenting.technology Cc: "freebsd-emulation@freebsd.org" , freebsd-current References: <36923A7F-23DE-490D-B1FA-A8B064740BD6@unrelenting.technology> <202111022148.1A2LmeHX004930@slippy.cwsent.com> In-Reply-To: <202111022148.1A2LmeHX004930@slippy.cwsent.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4HkPmJ0c6Sz4ZT1 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=protected-networks.net header.s=201508 header.b=N57G0ScY; dmarc=pass (policy=reject) header.from=protected-networks.net; spf=pass (mx1.freebsd.org: domain of imb@protected-networks.net designates 2001:470:8d59:1::8 as permitted sender) smtp.mailfrom=imb@protected-networks.net X-Spamd-Result: default: False [-3.07 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[protected-networks.net:s=201508]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[protected-networks.net:+]; DMARC_POLICY_ALLOW(-0.50)[protected-networks.net,reject]; NEURAL_HAM_SHORT(-0.07)[-0.068]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] Reply-To: imb@protected-networks.net From: Michael Butler via freebsd-emulation X-Original-From: Michael Butler X-ThisMailContainsUnwantedMimeParts: N On 11/2/21 17:48, Cy Schubert wrote: > In message <36923A7F-23DE-490D-B1FA-A8B064740BD6@unrelenting.technology>, > Greg > V via freebsd-current writes: >> >> >> On November 2, 2021 5:16:35 PM GMT+03:00, Michael Butler via freebsd-current >> wrote: >>> On current as of this morning (I haven't tried to bisect yet) .. >>> >>> .. with either graphics/drm-devel-kmod or graphics/drm-current-kmod, >>> trying to start a VirtualBox VM triggers this panic .. >>> >> >>> #16 0xffffffff80c81fc8 at calltrap+0x8 >>> #17 0xffffffff808b4d69 at sysctl_kern_proc_pathname+0xc9 >> >> something something https://reviews.freebsd.org/D32738 ? sysctl_kern_proc_pat >> hname was touched recently there. >> >> (Also can someone commit https://reviews.freebsd.org/D30174 ? These warning-f >> illed reports are unreadable >_<) > > Usually the first thing to do with virtualbox is rebuild it. That usually > fixes any panics I experience here. Of course, make sure your virtualbox > ports subdirs are fully patched, as it's an opportune time to update it too. Before reporting this, I rebuilt world including kernel, all kmods and virtualbox itself to no avail :-( I agree; most issues I've had in the past have been resolvable using this approach. Not this time, Michael From nobody Wed Nov 3 14:36:34 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id A7A8F183A824; Wed, 3 Nov 2021 14:37:09 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io1-f46.google.com (mail-io1-f46.google.com [209.85.166.46]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Hkq9K48J9z3LN0; Wed, 3 Nov 2021 14:37:09 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io1-f46.google.com with SMTP id p193so2990630iod.8; Wed, 03 Nov 2021 07:37:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Te6Okj60HWvjaIc8hUAjFCSIj5AJMWlfVS3LvBhiBOU=; b=oXrotjxNUEMjcEGm4PLOC4RjXQbuhH9QCXHcoBl5moy4LJFY9j0oDVko6i2AXx4Byi KuXyWxMyzLiquA6rGyyrInEKmzX3BM4goC/Kbgk/YsTrh3kdfGazEmvIjOsPd5lOTcMj gvbbIPsdiElj0ow84V7Ty5fJ2xjPzO9CpHJYsAJ84UhIuFOR+PHsJj9JiU5dzCAiRd06 6ikcmYJJViN9HiYZhUDJw0XjwPLdFpg10q+69dxTykSmeFOOAwx9qTBu704ugpwDr4ri /pLSQAwGTpkntLyLeF/nLpJlLQhCPhZR6EPrmIO9vXJ+eNgZuJ3a67KfjidaR9rttWmV r+lw== X-Gm-Message-State: AOAM530qwgmqHeJKVnmGcPlOvX2HNYMX0u0ODmVWKSOp3bXmH0cqzc80 RsHm6j4+IuSEnimcZB5Z9zhVkcHWBjc9cta7iFW9oidy X-Google-Smtp-Source: ABdhPJxCb0Bh/ie25ZRPIgSQzeJuSfokguHM+oAXnjRST1lgIDRuONg1V5nsX/zgK6boBTppK0zE/7Nc2XDjKxcY96M= X-Received: by 2002:a05:6602:1607:: with SMTP id x7mr9846612iow.134.1635950223438; Wed, 03 Nov 2021 07:37:03 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <36923A7F-23DE-490D-B1FA-A8B064740BD6@unrelenting.technology> <202111022148.1A2LmeHX004930@slippy.cwsent.com> <1ccb6ce3-2cb7-e325-79e3-cda5640f24df@protected-networks.net> In-Reply-To: <1ccb6ce3-2cb7-e325-79e3-cda5640f24df@protected-networks.net> From: Ed Maste Date: Wed, 3 Nov 2021 10:36:34 -0400 Message-ID: Subject: Re: current now panics when starting VBox VM To: Iain Michael Butler Cc: Cy Schubert , Greg V , "freebsd-emulation@freebsd.org" , freebsd-current Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4Hkq9K48J9z3LN0 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Tue, 2 Nov 2021 at 18:32, Michael Butler via freebsd-emulation wrote: > > Before reporting this, I rebuilt world including kernel, all kmods and > virtualbox itself to no avail :-( Thanks for confirming. Now that the WARN_ON noise is disabled by default would you mind rebuilding a new kernel and obtaining a less-noisy log? From nobody Wed Nov 3 15:05:11 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 69D3F1848081; Wed, 3 Nov 2021 15:05:23 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from mail.protected-networks.net (mail.protected-networks.net [202.12.127.228]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mail.protected-networks.net", Issuer "R3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Hkqnv223sz3my6; Wed, 3 Nov 2021 15:05:23 +0000 (UTC) (envelope-from imb@protected-networks.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d= protected-networks.net; h=content-transfer-encoding:content-type :content-type:in-reply-to:from:from:references:content-language :subject:subject:user-agent:mime-version:date:date:message-id; s=201508; t=1635951911; bh=KwAV4FXtAdB03WsMYUqaDDBrrPSYGa0K/Krw 63T25fU=; b=Tcw7dl422jIC1LXEhYWt6U5DIQr54ybV8sVwtvTUxnnktSE7vupy iZESNb1BaA+JTWJZNg8CwejH9DU1hzMu7692J9O6Bl6EmtqwMbD6oONgGwCEVeOm T88Q6zbaqolLZceQiSsIw0buGgnKLMedNJWFF7cW0NdUBKTbC2udkvo= Received: from [192.168.1.10] (toshi.auburn.protected-networks.net [192.168.1.10]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: imb@mail.protected-networks.net) by mail.protected-networks.net (Postfix) with ESMTPSA id C82A28515; Wed, 3 Nov 2021 11:05:11 -0400 (EDT) Message-ID: Date: Wed, 3 Nov 2021 11:05:11 -0400 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Subject: Re: current now panics when starting VBox VM Content-Language: en-NZ To: Ed Maste Cc: Cy Schubert , Greg V , "freebsd-emulation@freebsd.org" , freebsd-current References: <36923A7F-23DE-490D-B1FA-A8B064740BD6@unrelenting.technology> <202111022148.1A2LmeHX004930@slippy.cwsent.com> <1ccb6ce3-2cb7-e325-79e3-cda5640f24df@protected-networks.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4Hkqnv223sz3my6 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: imb@protected-networks.net From: Michael Butler via freebsd-emulation X-Original-From: Michael Butler X-ThisMailContainsUnwantedMimeParts: N On 11/3/21 10:36, Ed Maste wrote: > On Tue, 2 Nov 2021 at 18:32, Michael Butler via freebsd-emulation > wrote: >> >> Before reporting this, I rebuilt world including kernel, all kmods and >> virtualbox itself to no avail :-( > > Thanks for confirming. > > Now that the WARN_ON noise is disabled by default would you mind > rebuilding a new kernel and obtaining a less-noisy log? Dump header from device: /dev/ada1s3b Architecture: amd64 Architecture Version: 2 Dump Length: 853581824 Blocksize: 512 Compression: none Dumptime: 2021-11-03 10:57:00 -0400 Hostname: toshi.auburn.protected-networks.net Magic: FreeBSD Kernel Dump Version String: FreeBSD 14.0-CURRENT #50 main-dbfe5dd3f9: Wed Nov 3 10:26:58 EDT 2021 root@toshi.auburn.protected-networks.net:/usr/obj/usr/src/amd64.amd64/sys/TOSHI Panic String: page fault Dump Parity: 351593830 Bounds: 0 Dump Status: good Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x0 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff80ca54e4 stack pointer = 0x28:0xfffffe0129a6ab80 frame pointer = 0x28:0xfffffe0129a6ab80 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 = 1384 (plasmashell) trap number = 12 WARNING !drm_modeset_is_locked(&crtc->mutex) failed at /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:621 WARNING !drm_modeset_is_locked(&crtc->mutex) failed at /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:621 WARNING !drm_modeset_is_locked(&crtc->mutex) failed at /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:621 WARNING !drm_modeset_is_locked(&dev->mode_config.connection_mutex) failed at /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:666 WARNING !drm_modeset_is_locked(&plane->mutex) failed at /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:871 WARNING !drm_modeset_is_locked(&plane->mutex) failed at /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:871 WARNING !drm_modeset_is_locked(&plane->mutex) failed at /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:871 WARNING !drm_modeset_is_locked(&plane->mutex) failed at /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:871 WARNING !drm_modeset_is_locked(&plane->mutex) failed at /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:871 WARNING !drm_modeset_is_locked(&plane->mutex) failed at /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:871 WARNING !drm_modeset_is_locked(&plane->mutex) failed at /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:871 WARNING !drm_modeset_is_locked(&plane->mutex) failed at /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:871 WARNING !drm_modeset_is_locked(&plane->mutex) failed at /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:871 WARN_ON(!mutex_is_locked(&dev->struct_mutex)) WARN_ON(!mutex_is_locked(&fbc->lock))WARN_ON(!mutex_is_locked(&fbc->lock))WARN_ON(!mutex_is_locked(&fbc->lock)) panic: page fault cpuid = 0 time = 1635951420 WARNING !drm_modeset_is_locked(&crtc->mutex) failed at /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:621 WARNING !drm_modeset_is_locked(&crtc->mutex) failed at /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:621 WARNING !drm_modeset_is_locked(&crtc->mutex) failed at /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:621 WARNING !drm_modeset_is_locked(&dev->mode_config.connection_mutex) failed at /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:666 WARNING !drm_modeset_is_locked(&plane->mutex) failed at /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:871 WARNING !drm_modeset_is_locked(&plane->mutex) failed at /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:871 WARNING !drm_modeset_is_locked(&plane->mutex) failed at /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:871 WARNING !drm_modeset_is_locked(&plane->mutex) failed at /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:871 WARNING !drm_modeset_is_locked(&plane->mutex) failed at /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:871 WARNING !drm_modeset_is_locked(&plane->mutex) failed at /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:871 WARNING !drm_modeset_is_locked(&plane->mutex) failed at /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:871 WARNING !drm_modeset_is_locked(&plane->mutex) failed at /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:871 WARNING !drm_modeset_is_locked(&plane->mutex) failed at /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:871 WARN_ON(!mutex_is_locked(&dev->struct_mutex)) WARN_ON(!mutex_is_locked(&fbc->lock))WARN_ON(!mutex_is_locked(&fbc->lock))WARN_ON(!mutex_is_locked(&fbc->lock)) Uptime: 1m22s WARNING !drm_modeset_is_locked(&crtc->mutex) failed at /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:621 WARNING !drm_modeset_is_locked(&crtc->mutex) failed at /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:621 WARNING !drm_modeset_is_locked(&crtc->mutex) failed at /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:621 WARNING !drm_modeset_is_locked(&dev->mode_config.connection_mutex) failed at /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:666 WARNING !drm_modeset_is_locked(&plane->mutex) failed at /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:871 WARNING !drm_modeset_is_locked(&plane->mutex) failed at /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:871 WARNING !drm_modeset_is_locked(&plane->mutex) failed at /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:871 WARNING !drm_modeset_is_locked(&plane->mutex) failed at /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:871 WARNING !drm_modeset_is_locked(&plane->mutex) failed at /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:871 WARNING !drm_modeset_is_locked(&plane->mutex) failed at /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:871 WARNING !drm_modeset_is_locked(&plane->mutex) failed at /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:871 WARNING !drm_modeset_is_locked(&plane->mutex) failed at /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:871 WARNING !drm_modeset_is_locked(&plane->mutex) failed at /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.144_2/drivers/gpu/drm/drm_atomic_helper.c:871 WARN_ON(!mutex_is_locked(&dev->struct_mutex)) WARN_ON(!mutex_is_locked(&fbc->lock))WARN_ON(!mutex_is_locked(&fbc->lock))WARN_ON(!mutex_is_locked(&fbc->lock)) Dumping 814 out of 16257 MB:..2%..12%..22%..32%..42%..52%..61%..71%..81%..91% The kgdb back-trace isn't any more enlightening to me :-( __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55 55 __asm("movq %%gs:%P1,%0" : "=r" (td) : "n" (offsetof(struct pcpu, (kgdb) bt #0 __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55 #1 doadump (textdump=) at /usr/src/sys/kern/kern_shutdown.c:399 #2 0xffffffff808cbac5 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:487 #3 0xffffffff808cbedb in vpanic (fmt=, ap=0xfffffe0129a6a8d0) at /usr/src/sys/kern/kern_shutdown.c:920 #4 0xffffffff808cbd33 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:844 #5 0xffffffff80ca920c in trap_fatal (frame=frame@entry=0xfffffe0129a6aac0, eva=0) at /usr/src/sys/amd64/amd64/trap.c:946 #6 0xffffffff80ca95af in trap_pfault (frame=frame@entry=0xfffffe0129a6aac0, usermode=false, signo=, signo@entry=0x0, ucode=, ucode@entry=0x0) at /usr/src/sys/amd64/include/cpufunc.h:417 #7 0xffffffff80ca89bc in trap (frame=0xfffffe0129a6aac0) at /usr/src/sys/amd64/amd64/trap.c:443 #8 #9 strlen () at /usr/src/sys/amd64/amd64/support.S:751 #10 0xffffffff808b4d79 in sysctl_kern_proc_pathname (oidp=, arg1=0xfffffe0129a6ad8c, arg2=, req=0xfffffe0129a6acc0) at /usr/src/sys/kern/kern_proc.c:2330 #11 0xffffffff808dc331 in sysctl_root_handler_locked (oid=oid@entry=0xffffffff810cf0e0 , arg1=arg1@entry=0xfffffe0129a6ad8c, arg2=arg2@entry=1, req=0xfffffe0129a6acc0, tracker=tracker@entry=0xfffffe0129a6ac38) at /usr/src/sys/kern/kern_sysctl.c:185 #12 0xffffffff808db88b in sysctl_root (oidp=, arg1=0xfffffe0129a6ad8c, arg1@entry=0xfffffe0129a6ad80, arg2=1, arg2@entry=4, req=req@entry=0xfffffe0129a6acc0) at /usr/src/sys/kern/kern_sysctl.c:2305 #13 0xffffffff808dbdf3 in userland_sysctl (td=td@entry=0xfffffe012991a000, name=name@entry=0xfffffe0129a6ad80, namelen=4, old=, oldlenp=, inkernel=, inkernel@entry=0, new=0x0, newlen=0, retval=0xfffffe0129a6ade8, flags=0) at /usr/src/sys/kern/kern_sysctl.c:2462 #14 0xffffffff808dbc3c in sys___sysctl (td=0xfffffe012991a000, uap=0xfffffe012991a3f0) at /usr/src/sys/kern/kern_sysctl.c:2335 #15 0xffffffff80ca9b5c in syscallenter (td=0xfffffe012991a000) at /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:189 #16 amd64_syscall (td=0xfffffe012991a000, traced=0) at /usr/src/sys/amd64/amd64/trap.c:1191 #17 #18 0x000000080315a71a in ?? () Backtrace stopped: Cannot access memory at address 0x7fffffffc778 (kgdb) Michael From nobody Wed Nov 3 15:13:03 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 45B29184C436; Wed, 3 Nov 2021 15:13:16 +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) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Hkqz0042Xz3rbf; Wed, 3 Nov 2021 15:13:15 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 1A3FD32r042875 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 3 Nov 2021 17:13:06 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 1A3FD32r042875 Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 1A3FD3p2042874; Wed, 3 Nov 2021 17:13:03 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 3 Nov 2021 17:13:03 +0200 From: Konstantin Belousov To: imb@protected-networks.net Cc: Ed Maste , Cy Schubert , Greg V , "freebsd-emulation@freebsd.org" , freebsd-current Subject: Re: current now panics when starting VBox VM Message-ID: References: <36923A7F-23DE-490D-B1FA-A8B064740BD6@unrelenting.technology> <202111022148.1A2LmeHX004930@slippy.cwsent.com> <1ccb6ce3-2cb7-e325-79e3-cda5640f24df@protected-networks.net> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org 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.5 X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on tom.home X-Rspamd-Queue-Id: 4Hkqz0042Xz3rbf X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Wed, Nov 03, 2021 at 11:05:11AM -0400, Michael Butler via freebsd-emulation wrote: > On 11/3/21 10:36, Ed Maste wrote: > The kgdb back-trace isn't any more enlightening to me :-( > > __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55 > 55 __asm("movq %%gs:%P1,%0" : "=r" (td) : "n" (offsetof(struct > pcpu, > (kgdb) bt > #0 __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55 > #1 doadump (textdump=) at > /usr/src/sys/kern/kern_shutdown.c:399 > #2 0xffffffff808cbac5 in kern_reboot (howto=260) at > /usr/src/sys/kern/kern_shutdown.c:487 > #3 0xffffffff808cbedb in vpanic (fmt=, > ap=0xfffffe0129a6a8d0) at /usr/src/sys/kern/kern_shutdown.c:920 > #4 0xffffffff808cbd33 in panic (fmt=) at > /usr/src/sys/kern/kern_shutdown.c:844 > #5 0xffffffff80ca920c in trap_fatal (frame=frame@entry=0xfffffe0129a6aac0, > eva=0) at /usr/src/sys/amd64/amd64/trap.c:946 > #6 0xffffffff80ca95af in trap_pfault (frame=frame@entry=0xfffffe0129a6aac0, > usermode=false, signo=, signo@entry=0x0, ucode= out>, ucode@entry=0x0) > at /usr/src/sys/amd64/include/cpufunc.h:417 > #7 0xffffffff80ca89bc in trap (frame=0xfffffe0129a6aac0) at > /usr/src/sys/amd64/amd64/trap.c:443 > #8 > #9 strlen () at /usr/src/sys/amd64/amd64/support.S:751 > #10 0xffffffff808b4d79 in sysctl_kern_proc_pathname (oidp=, > arg1=0xfffffe0129a6ad8c, arg2=, req=0xfffffe0129a6acc0) at > /usr/src/sys/kern/kern_proc.c:2330 > #11 0xffffffff808dc331 in sysctl_root_handler_locked > (oid=oid@entry=0xffffffff810cf0e0 , > arg1=arg1@entry=0xfffffe0129a6ad8c, arg2=arg2@entry=1, > req=0xfffffe0129a6acc0, tracker=tracker@entry=0xfffffe0129a6ac38) at > /usr/src/sys/kern/kern_sysctl.c:185 > #12 0xffffffff808db88b in sysctl_root (oidp=, > arg1=0xfffffe0129a6ad8c, arg1@entry=0xfffffe0129a6ad80, arg2=1, > arg2@entry=4, req=req@entry=0xfffffe0129a6acc0) > at /usr/src/sys/kern/kern_sysctl.c:2305 > #13 0xffffffff808dbdf3 in userland_sysctl (td=td@entry=0xfffffe012991a000, > name=name@entry=0xfffffe0129a6ad80, namelen=4, old=, > oldlenp=, > inkernel=, inkernel@entry=0, new=0x0, newlen=0, > retval=0xfffffe0129a6ade8, flags=0) at /usr/src/sys/kern/kern_sysctl.c:2462 > #14 0xffffffff808dbc3c in sys___sysctl (td=0xfffffe012991a000, > uap=0xfffffe012991a3f0) at /usr/src/sys/kern/kern_sysctl.c:2335 > #15 0xffffffff80ca9b5c in syscallenter (td=0xfffffe012991a000) at > /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:189 > #16 amd64_syscall (td=0xfffffe012991a000, traced=0) at > /usr/src/sys/amd64/amd64/trap.c:1191 > #17 > #18 0x000000080315a71a in ?? () > Backtrace stopped: Cannot access memory at address 0x7fffffffc778 > (kgdb) > Try this commit 2d3f95bd1fd4f71769f60b8037c1ff27c75d8258 Author: Konstantin Belousov Date: Wed Nov 3 17:11:33 2021 +0200 proc_get_binpath(): return empty string instead of NULL for strange case where process does not have text. Sponsored by: The FreeBSD Foundation MFC after: 3 days diff --git a/sys/kern/kern_proc.c b/sys/kern/kern_proc.c index 2156c5c465ba..d11f651960c0 100644 --- a/sys/kern/kern_proc.c +++ b/sys/kern/kern_proc.c @@ -2252,7 +2252,7 @@ proc_get_binpath(struct proc *p, char *binname, char **retbuf, vp = p->p_textvp; if (vp == NULL) { PROC_UNLOCK(p); - *retbuf = NULL; + *retbuf = ""; *freebuf = NULL; return (0); } From nobody Wed Nov 3 15:25:53 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 2A8161824336; Wed, 3 Nov 2021 15:26:02 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from mail.protected-networks.net (mail.protected-networks.net [IPv6:2001:470:8d59:1::8]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mail.protected-networks.net", Issuer "R3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HkrFk022gz4SrW; Wed, 3 Nov 2021 15:26:01 +0000 (UTC) (envelope-from imb@protected-networks.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d= protected-networks.net; h=content-transfer-encoding:content-type :content-type:in-reply-to:from:from:references:content-language :subject:subject:user-agent:mime-version:date:date:message-id; s=201508; t=1635953153; bh=m1/X7QF0hPIvg9DlDXA93xZFq//vlioN4Cw+ 1T4SOEY=; b=kAUNHPirE4YWKFq7MQEe7Ev/G62gyGFwEO6gmh2bCkAGJVWr/I5f bblfW0J1PV+5OlX/R0pV5UTXyf1lQqBFBoBAEpz05lKq8yn8lnPVaNpE1elQSlL0 N31vQZwB0WdMPpddxYHd9kvhJfJSgct7bca8iqkJswIYEDtgHtwHgwc= Received: from [192.168.1.10] (toshi.auburn.protected-networks.net [192.168.1.10]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: imb@mail.protected-networks.net) by mail.protected-networks.net (Postfix) with ESMTPSA id ED804CF7A; Wed, 3 Nov 2021 11:25:53 -0400 (EDT) Message-ID: <20712a48-03d3-722e-3990-e70b9670af1d@protected-networks.net> Date: Wed, 3 Nov 2021 11:25:53 -0400 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Subject: Re: current now panics when starting VBox VM Content-Language: en-NZ To: Konstantin Belousov Cc: Ed Maste , Cy Schubert , Greg V , "freebsd-emulation@freebsd.org" , freebsd-current References: <36923A7F-23DE-490D-B1FA-A8B064740BD6@unrelenting.technology> <202111022148.1A2LmeHX004930@slippy.cwsent.com> <1ccb6ce3-2cb7-e325-79e3-cda5640f24df@protected-networks.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4HkrFk022gz4SrW X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: imb@protected-networks.net From: Michael Butler via freebsd-emulation X-Original-From: Michael Butler X-ThisMailContainsUnwantedMimeParts: N On 11/3/21 11:13, Konstantin Belousov wrote: > On Wed, Nov 03, 2021 at 11:05:11AM -0400, Michael Butler via freebsd-emulation wrote: >> On 11/3/21 10:36, Ed Maste wrote: >> The kgdb back-trace isn't any more enlightening to me :-( >> >> __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55 >> 55 __asm("movq %%gs:%P1,%0" : "=r" (td) : "n" (offsetof(struct >> pcpu, >> (kgdb) bt >> #0 __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55 >> #1 doadump (textdump=) at >> /usr/src/sys/kern/kern_shutdown.c:399 >> #2 0xffffffff808cbac5 in kern_reboot (howto=260) at >> /usr/src/sys/kern/kern_shutdown.c:487 >> #3 0xffffffff808cbedb in vpanic (fmt=, >> ap=0xfffffe0129a6a8d0) at /usr/src/sys/kern/kern_shutdown.c:920 >> #4 0xffffffff808cbd33 in panic (fmt=) at >> /usr/src/sys/kern/kern_shutdown.c:844 >> #5 0xffffffff80ca920c in trap_fatal (frame=frame@entry=0xfffffe0129a6aac0, >> eva=0) at /usr/src/sys/amd64/amd64/trap.c:946 >> #6 0xffffffff80ca95af in trap_pfault (frame=frame@entry=0xfffffe0129a6aac0, >> usermode=false, signo=, signo@entry=0x0, ucode=> out>, ucode@entry=0x0) >> at /usr/src/sys/amd64/include/cpufunc.h:417 >> #7 0xffffffff80ca89bc in trap (frame=0xfffffe0129a6aac0) at >> /usr/src/sys/amd64/amd64/trap.c:443 >> #8 >> #9 strlen () at /usr/src/sys/amd64/amd64/support.S:751 >> #10 0xffffffff808b4d79 in sysctl_kern_proc_pathname (oidp=, >> arg1=0xfffffe0129a6ad8c, arg2=, req=0xfffffe0129a6acc0) at >> /usr/src/sys/kern/kern_proc.c:2330 >> #11 0xffffffff808dc331 in sysctl_root_handler_locked >> (oid=oid@entry=0xffffffff810cf0e0 , >> arg1=arg1@entry=0xfffffe0129a6ad8c, arg2=arg2@entry=1, >> req=0xfffffe0129a6acc0, tracker=tracker@entry=0xfffffe0129a6ac38) at >> /usr/src/sys/kern/kern_sysctl.c:185 >> #12 0xffffffff808db88b in sysctl_root (oidp=, >> arg1=0xfffffe0129a6ad8c, arg1@entry=0xfffffe0129a6ad80, arg2=1, >> arg2@entry=4, req=req@entry=0xfffffe0129a6acc0) >> at /usr/src/sys/kern/kern_sysctl.c:2305 >> #13 0xffffffff808dbdf3 in userland_sysctl (td=td@entry=0xfffffe012991a000, >> name=name@entry=0xfffffe0129a6ad80, namelen=4, old=, >> oldlenp=, >> inkernel=, inkernel@entry=0, new=0x0, newlen=0, >> retval=0xfffffe0129a6ade8, flags=0) at /usr/src/sys/kern/kern_sysctl.c:2462 >> #14 0xffffffff808dbc3c in sys___sysctl (td=0xfffffe012991a000, >> uap=0xfffffe012991a3f0) at /usr/src/sys/kern/kern_sysctl.c:2335 >> #15 0xffffffff80ca9b5c in syscallenter (td=0xfffffe012991a000) at >> /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:189 >> #16 amd64_syscall (td=0xfffffe012991a000, traced=0) at >> /usr/src/sys/amd64/amd64/trap.c:1191 >> #17 >> #18 0x000000080315a71a in ?? () >> Backtrace stopped: Cannot access memory at address 0x7fffffffc778 >> (kgdb) >> > > Try this > > commit 2d3f95bd1fd4f71769f60b8037c1ff27c75d8258 > Author: Konstantin Belousov > Date: Wed Nov 3 17:11:33 2021 +0200 > > proc_get_binpath(): return empty string instead of NULL > > for strange case where process does not have text. > > Sponsored by: The FreeBSD Foundation > MFC after: 3 days > > diff --git a/sys/kern/kern_proc.c b/sys/kern/kern_proc.c > index 2156c5c465ba..d11f651960c0 100644 > --- a/sys/kern/kern_proc.c > +++ b/sys/kern/kern_proc.c > @@ -2252,7 +2252,7 @@ proc_get_binpath(struct proc *p, char *binname, char **retbuf, > vp = p->p_textvp; > if (vp == NULL) { > PROC_UNLOCK(p); > - *retbuf = NULL; > + *retbuf = ""; > *freebuf = NULL; > return (0); > } > Interestingly, when I went to log out of KDE afer applying this patch and rebuilding the kernel, it also paniced without VBox ruuning. The log looks similar but the back-trace points to this possibility .. see frames 8 through 10 . __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55 55 __asm("movq %%gs:%P1,%0" : "=r" (td) : "n" (offsetof(struct pcpu, (kgdb) #0 __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55 #1 doadump (textdump=) at /usr/src/sys/kern/kern_shutdown.c:399 #2 0xffffffff808cbac5 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:487 #3 0xffffffff808cbedb in vpanic (fmt=, ap=0xfffffe011c1858d0) at /usr/src/sys/kern/kern_shutdown.c:920 #4 0xffffffff808cbd33 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:844 #5 0xffffffff80ca920c in trap_fatal (frame=frame@entry=0xfffffe011c185ac0, eva=0) at /usr/src/sys/amd64/amd64/trap.c:946 #6 0xffffffff80ca95af in trap_pfault (frame=frame@entry=0xfffffe011c185ac0, usermode=false, signo=, signo@entry=0x0, ucode=, ucode@entry=0x0) at /usr/src/sys/amd64/include/cpufunc.h:417 #7 0xffffffff80ca89bc in trap (frame=0xfffffe011c185ac0) at /usr/src/sys/amd64/amd64/trap.c:443 #8 #9 strlen () at /usr/src/sys/amd64/amd64/support.S:751 #10 0xffffffff808b4d79 in sysctl_kern_proc_pathname (oidp=, arg1=0xfffffe011c185d8c, arg2=, req=0xfffffe011c185cc0) at /usr/src/sys/kern/kern_proc.c:2330 #11 0xffffffff808dc331 in sysctl_root_handler_locked ( oid=oid@entry=0xffffffff810cf0e0 , arg1=arg1@entry=0xfffffe011c185d8c, arg2=arg2@entry=1, req=0xfffffe011c185cc0, tracker=tracker@entry=0xfffffe011c185c38) at /usr/src/sys/kern/kern_sysctl.c:185 After rebooting with this patch, I can now run a VBox VM without provoking a panic. Thanks! :-) Michael From nobody Fri Nov 5 01:07:33 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 782A31837CD2 for ; Fri, 5 Nov 2021 01:07:42 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Hlj6P420lz3HR8 for ; Fri, 5 Nov 2021 01:07:41 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.16.1/8.16.1) with ESMTPS id 1A517X93016381 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Thu, 4 Nov 2021 18:07:33 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.16.1/8.16.1/Submit) id 1A517XwM016380 for freebsd-current@freebsd.org; Thu, 4 Nov 2021 18:07:33 -0700 (PDT) (envelope-from sgk) Date: Thu, 4 Nov 2021 18:07:33 -0700 From: Steve Kargl To: freebsd-current@freebsd.org Subject: [LIBM] One step closer to C99 conformance Message-ID: <20211105010733.GA16355@troutmask.apl.washington.edu> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Rspamd-Queue-Id: 4Hlj6P420lz3HR8 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=washington.edu (policy=none); spf=none (mx1.freebsd.org: domain of sgk@troutmask.apl.washington.edu has no SPF policy when checking 128.95.76.21) smtp.mailfrom=sgk@troutmask.apl.washington.edu X-Spamd-Result: default: False [0.62 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.71)[-0.708]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; NEURAL_SPAM_MEDIUM(0.32)[0.323]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_SPAM_SHORT(1.00)[1.000]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DMARC_POLICY_SOFTFAIL(0.10)[washington.edu : No valid SPF, No valid DKIM,none] X-ThisMailContainsUnwantedMimeParts: N A patch has been attached to https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216862 which implements cexpl(). Note, the patch includes some bug fixes for libm on ld128 hardware. -- Steve From nobody Fri Nov 5 17:25:19 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id C8CEC183535A for ; Fri, 5 Nov 2021 17:25:33 +0000 (UTC) (envelope-from obiwac@gmail.com) Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Hm6ph4dd1z4dCn for ; Fri, 5 Nov 2021 17:25:32 +0000 (UTC) (envelope-from obiwac@gmail.com) Received: by mail-ed1-x529.google.com with SMTP id m14so34791349edd.0 for ; Fri, 05 Nov 2021 10:25:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=7WpwGQ1P1cxUxNxLqaNHIWJ5zo9Tf76MlpU+sAjxPfs=; b=czLnsahQ3YCf9S4122rBt5i/MnVUlPRLvRKEHG7mHXEfq/YJSFWCtE+f0D0t1hBekH hacOTDakOgymcmMDMPKYxk+Rr2ycpzPhfUkZAN7DtknVerIwTXiHu2Jd3aXuKdp+b1Da BlYvhkaePovxXpJH7bvZwREuN0ZN+/3MLXA4sRn/4kwipqm6Jk2Mi5MoCJlipkuv5W+R 6XVk7mk21ezZzRwXaVU9W6HO+MDBXJVzNKOqGrSaHd3jCtZsANBbhW/01d553tBxLwRw bxv0apKMNebXK+eeQco7+mKUxAnwUOzE3szX+zrDQA6S+pGjYoYXFkKLWGscGtaScPpi EY0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=7WpwGQ1P1cxUxNxLqaNHIWJ5zo9Tf76MlpU+sAjxPfs=; b=71U6A/BFuzcTcir37GHlr25zTo/7NWcqxpraNeCo14qRE2eq4zpyZY6x+ZeeNhe835 DggZhlSfr7DWfZyl94c8vA0cp0gWRYx5KgN8XqBJtMyahRZDhJ8i2ENvvfOk0NXwClDI I+rnGKNultI/hNzguqCjU21avp+BoCfxhGEn+KPvZmvYv+X1swWobe1eVc8WCXntxj7q uB4qSHkliROmHoqJfss2LKUjfldrOjlHGchdvJbdo8S1Rw7tge/K0Yt4PCIGnJW5Qa0I KNx89E/aDDx0zbS+1RIktgjUCIs9+7A2+IEFtBsdA5RQAC3hw+ZfFkDrsxa1MGoVHYw3 1iaw== X-Gm-Message-State: AOAM5307w7mkUmS0CPMLpGr4Hmt3PUFXaKLKRTt41Pwlc20/I0OnL+V7 JZHtcApUFgG/cdixhgSZV56RNluM2qBYxqwkqjlm1PMVaOI= X-Google-Smtp-Source: ABdhPJwbFu8f0Pg9OtsndIKalWU0Bq8xZTA6X/vfY6xqj7rSi5ArCnBaNldYP2PUW+gI6s1Mpx/81CR9q8oFXzrbFuI= X-Received: by 2002:a17:907:6da4:: with SMTP id sb36mr5007760ejc.40.1636133130797; Fri, 05 Nov 2021 10:25:30 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 From: obiwac Date: Fri, 5 Nov 2021 18:25:19 +0100 Message-ID: Subject: Potential bug in the dynamic linker? To: freebsd-current@freebsd.org Content-Type: multipart/alternative; boundary="00000000000011101005d00dee84" X-Rspamd-Queue-Id: 4Hm6ph4dd1z4dCn X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=czLnsahQ; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of obiwac@gmail.com designates 2a00:1450:4864:20::529 as permitted sender) smtp.mailfrom=obiwac@gmail.com X-Spamd-Result: default: False [-2.99 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; NEURAL_HAM_MEDIUM(-1.00)[-0.997]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.99)[-0.991]; MID_RHS_MATCH_FROMTLD(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::529:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: Y --00000000000011101005d00dee84 Content-Type: text/plain; charset="UTF-8" Let me preface this by saying that I am in no way knowledgeable enough regarding the FreeBSD dynamic linker to know whether or not this is infact a bug or intended behaviour. This program I'm working on, when compiled for FreeBSD, calls fdlopen(3) to load a dynamic library from memory. This is how I'm doing that more specifically: // void* lib_bin, size_t lib_len int fd = shm_open(SHM_ANON, O_RDWR, 0); ftruncate(fd, lib_len); void* lib_mem = mmap(NULL, lib_len, PROT_WRITE, MAP_SHARED, fd, 0); memcpy(lib_mem, lib_bin, lib_len); munmap(lib_mem, lib_len); void* lib = fdlopen(fd, RTLD_LAZY); close(fd); Running this on FreeBSD 13 works fine, FreeBSD 14, however, spits out this error: Cannot fstatfs "" Digging around, I find, in libexec/rtld-elf/rtld.c: /* * but first, make sure that environment variables haven't been * used to circumvent the noexec flag on a filesystem. */ if (dangerous_ld_env) { if (fstatfs(fd, &fs) != 0) { _rtld_error("Cannot fstatfs \"%s\"", printable_path(path)); return NULL; } if (fs.f_flags & MNT_NOEXEC) { _rtld_error("Cannot execute objects on %s", fs.f_mntonname); return NULL; } } And this is the first thing that seems weird to me. Why is it calling fstatfs(3) before checking if the file descriptor doesn't necessarily refer to a file which resides on a physical filesystem? It doesn't say so on the manpage, but, again, digging around, that's what the error returned by fstatfs(3), EINVAL, supposedly means. Secondly, why then is dangerous_ld_env even set in the first place? Well, as of this commit (https://reviews.freebsd.org/D26352): ld_dynamic_weak = ld_get_env_var(LD_DYNAMIC_WEAK) == NULL; ... dangerous_ld_env = libmap_disable || libmap_override != NULL || ld_library_path != NULL || ld_preload != NULL || ld_elf_hints_path != NULL || ld_loadfltr || ld_dynamic_weak; Should this not be ld_dynamic_weak = ld_get_env_var(LD_DYNAMIC_WEAK) != NULL; instead? Or is this actually intended and am I just not understanding the point of this? --00000000000011101005d00dee84-- From nobody Fri Nov 5 17:25:42 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id C9FAD1835DDB for ; Fri, 5 Nov 2021 17:26:07 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-lf1-f54.google.com (mail-lf1-f54.google.com [209.85.167.54]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Hm6qM58Xyz4dmb for ; Fri, 5 Nov 2021 17:26:07 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-lf1-f54.google.com with SMTP id bi35so20079517lfb.9 for ; Fri, 05 Nov 2021 10:26:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sdtwGTWSZFZZ6oN7BOQsTZ5vuFmjOZ8RtJTZqkKObLE=; b=6WPN1D2j2SJRxRe2rVTAjFppNNkQWt158njmkbHX3wPXxKMQqw049dcpGBlejnF7M1 q8mU+PgREl6246uCeFkA1r1An1FNyIzffaKc+jsPN7qHzUWiDPn8TPvb+pcBGnxhL0G0 mHK3IZbxcULmPrSZ6HiJnt8k8ZYyGabnteTqXzRy2rjEDBR9vmi+EdKBrvUGUrnjppWL TzKbmP5IsQKeKcDG1hWli+vovr1aBnlC+09j6ZAWcbeN2NUbw0dkl8OuVmnA76zVGYrZ nw2QxY7mtss+zzaEIHZE67fIuUowJvHt1fkYWB14KK68yTk9hHdXNrhFDKWOh19kTqj7 ka2A== X-Gm-Message-State: AOAM531kWxb48gemFR9Fe2E31OMuqND8nAtzasJP0UxI+G1CS2yTkQg7 6pdXjMoy5weB0oqyvVOIZFDvQYUlm1CMZuVFMxd/WAgt X-Google-Smtp-Source: ABdhPJxlcw4eYuxmHJ8ZNChL7y0xnZAxVkIZW5qTVxNrlG5K5D8ZCB/kfuyQRMhYdkIhapTMcJlJoP5QtkRas13RaY4= X-Received: by 2002:a05:6512:3d14:: with SMTP id d20mr58555175lfv.542.1636133159748; Fri, 05 Nov 2021 10:25:59 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <20211105010733.GA16355@troutmask.apl.washington.edu> In-Reply-To: <20211105010733.GA16355@troutmask.apl.washington.edu> From: Ed Maste Date: Fri, 5 Nov 2021 13:25:42 -0400 Message-ID: Subject: Re: [LIBM] One step closer to C99 conformance To: Steve Kargl Cc: FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4Hm6qM58Xyz4dmb X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Thu, 4 Nov 2021 at 21:09, Steve Kargl wrote: > > A patch has been attached to > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216862 > > which implements cexpl(). Great, thank you Steve. Do you have a list of what else is left for full C99? (Including anything that may be implemented in a suboptimal way today and should be redone.) From nobody Fri Nov 5 17:27:33 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 66F8518371D5 for ; Fri, 5 Nov 2021 17:27:47 +0000 (UTC) (envelope-from obiwac@gmail.com) Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Hm6sG4fbFz4g6p for ; Fri, 5 Nov 2021 17:27:46 +0000 (UTC) (envelope-from obiwac@gmail.com) Received: by mail-ed1-x532.google.com with SMTP id f8so35725995edy.4 for ; Fri, 05 Nov 2021 10:27:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=LxQls+Otm674yQv2LWE7RfHNPcwTQvUpy0RW4OQBueg=; b=mjxsmrFWpHoBcfH+xByZghy6teHWW+zHr9UOE7kG6R4l1PdBzx2IGU8HjLAdf3Ky37 908UZ364D+15FDXrTJYrgpnNRAPy8drJ/1AH3EtJmx95Q0EkMJF0lrH4XrVbLg1CJJy5 ZURSzQlOTqrF08w4hEwxlxTVQtIHQ0mXaux3zxVUkX0ZzzQclq9eKXJ4gZluzMhVg2SC 4F/vIWvjBKPbx2xZ0RIKRLIZ266JlttzBf7QTddPIHPRuGkDC4QajBbxUvZurNxp2FY+ xS87WoqRw9K64aFLvvRfbDVLK+CrQ/fvPRtDsOdBPGys0hM2x6e6u05kCBefyC5K/2Fr GAmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=LxQls+Otm674yQv2LWE7RfHNPcwTQvUpy0RW4OQBueg=; b=IgIs7R0Uh3XO1XZwfP3Qt3Fd2qoY7ayy8a1Ff8vVqLdIQEr3++YKJ5ec+nsVBSh3rb n+1ghMhw1UveL5joO7GCsuotYdsl3V3fVJPtQqUOyWs4yhNgmXqBSAyygIdVfVEpWah1 uhYFUhFusXZuJRoPs4GSEDWoaGhwT0bDfiAokcRZ/1vLBXJk68f7U+rfFuQInH5xZKmM GF42TwWd00V6XP8nohuy+qS9y5IUuZiIb1t1L9F7MUCV7cOsnskr2tRgd0U7qiQq0bVA RqveC1zmsCQr2Z7HPLY31LJ29yhu+hMZWZorg3YjhFkyaT6oscuHOc3duUqFyxKqXbGc QBfQ== X-Gm-Message-State: AOAM531Ld85IYqq7gx6bvzFksuCXJ1ddtC0wKp+mYuf2q3A0MwN2HCvJ 7cYOFG23vdQOFSZ+gk0LL/efw6nndeyXHFFeN6zI9I83Ogw= X-Google-Smtp-Source: ABdhPJzRlZbwJIu6I5h0HaZ1DmVUQqppHN9tb03/3FMfMbOkkH+DIm/0k85EbBNtKCKsBZtM9ZGMwbkY/AVUfRKF9H4= X-Received: by 2002:a05:6402:520b:: with SMTP id s11mr41716388edd.213.1636133264936; Fri, 05 Nov 2021 10:27:44 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 From: obiwac Date: Fri, 5 Nov 2021 18:27:33 +0100 Message-ID: Subject: Potential bug in the dynamic linker? To: freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4Hm6sG4fbFz4g6p X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=mjxsmrFW; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of obiwac@gmail.com designates 2a00:1450:4864:20::532 as permitted sender) smtp.mailfrom=obiwac@gmail.com X-Spamd-Result: default: False [-0.99 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.997]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.99)[-0.992]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::532:from]; NEURAL_SPAM_SHORT(1.00)[1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; SUBJECT_ENDS_QUESTION(1.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Let me preface this by saying that I am in no way knowledgeable enough regarding the FreeBSD dynamic linker to know whether or not this is infact a bug or intended behaviour. This program I'm working on, when compiled for FreeBSD, calls fdlopen(3) to load a dynamic library from memory. This is how I'm doing that more specifically: // void* lib_bin, size_t lib_len int fd = shm_open(SHM_ANON, O_RDWR, 0); ftruncate(fd, lib_len); void* lib_mem = mmap(NULL, lib_len, PROT_WRITE, MAP_SHARED, fd, 0); memcpy(lib_mem, lib_bin, lib_len); munmap(lib_mem, lib_len); void* lib = fdlopen(fd, RTLD_LAZY); close(fd); Running this on FreeBSD 13 works fine, FreeBSD 14, however, spits out this error: Cannot fstatfs "" Digging around, I find, in libexec/rtld-elf/rtld.c: /* * but first, make sure that environment variables haven't been * used to circumvent the noexec flag on a filesystem. */ if (dangerous_ld_env) { if (fstatfs(fd, &fs) != 0) { _rtld_error("Cannot fstatfs \"%s\"", printable_path(path)); return NULL; } if (fs.f_flags & MNT_NOEXEC) { _rtld_error("Cannot execute objects on %s", fs.f_mntonname); return NULL; } } And this is the first thing that seems weird to me. Why is it calling fstatfs(3) before checking if the file descriptor doesn't necessarily refer to a file which resides on a physical filesystem? It doesn't say so on the manpage, but, again, digging around, that's what the error returned by fstatfs(3), EINVAL, supposedly means. Secondly, why then is dangerous_ld_env even set in the first place? Well, as of this commit (https://reviews.freebsd.org/D26352): ld_dynamic_weak = ld_get_env_var(LD_DYNAMIC_WEAK) == NULL; ... dangerous_ld_env = libmap_disable || libmap_override != NULL || ld_library_path != NULL || ld_preload != NULL || ld_elf_hints_path != NULL || ld_loadfltr || ld_dynamic_weak; Should this not be ld_dynamic_weak = ld_get_env_var(LD_DYNAMIC_WEAK) != NULL; instead? Or is this actually intended and am I just not understanding the point of this? From nobody Fri Nov 5 18:28:43 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id DD073183025D for ; Fri, 5 Nov 2021 18:28:45 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Hm8Cd4xtxz3JlJ; Fri, 5 Nov 2021 18:28:45 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.16.1/8.16.1) with ESMTPS id 1A5IShjX026382 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 5 Nov 2021 11:28:44 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.16.1/8.16.1/Submit) id 1A5IShK6026381; Fri, 5 Nov 2021 11:28:43 -0700 (PDT) (envelope-from sgk) Date: Fri, 5 Nov 2021 11:28:43 -0700 From: Steve Kargl To: Ed Maste Cc: FreeBSD Current Subject: Re: [LIBM] One step closer to C99 conformance Message-ID: <20211105182843.GA26300@troutmask.apl.washington.edu> References: <20211105010733.GA16355@troutmask.apl.washington.edu> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4Hm8Cd4xtxz3JlJ X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Fri, Nov 05, 2021 at 01:25:42PM -0400, Ed Maste wrote: > On Thu, 4 Nov 2021 at 21:09, Steve Kargl > wrote: > > > > A patch has been attached to > > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216862 > > > > which implements cexpl(). > > Great, thank you Steve. > > Do you have a list of what else is left for full C99? (Including > anything that may be implemented in a suboptimal way today and should > be redone.) I have ccoshl and ccosl implemented, but need to do some testing. Things that are missing ctanhl, ctanl, csinhl, and csinl. I have an old implementation of csinhl/csinl, but Bruce had some concerns with handling of NaN and +-inf. Need to dig up some old emails. tgammal, powl, and cpow[fl] are a mess as the people who committed code for these functions seem to have no interest in floating point math on FreeBSD. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89125 -- Steve From nobody Fri Nov 5 20:13:23 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id E6B60184F3CE for ; Fri, 5 Nov 2021 20:13:26 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HmBXP4nnRz557j; Fri, 5 Nov 2021 20:13:25 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.16.1/8.16.1) with ESMTPS id 1A5KDNFw026780 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 5 Nov 2021 13:13:24 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.16.1/8.16.1/Submit) id 1A5KDNrM026779; Fri, 5 Nov 2021 13:13:23 -0700 (PDT) (envelope-from sgk) Date: Fri, 5 Nov 2021 13:13:23 -0700 From: Steve Kargl To: freebsd-current@freebsd.org, lwhsu@freebsd.org, dim@freebsd.org Subject: WHY? commit ac76bc1145dd7f4476e5d982ce8f355f71015713 Message-ID: <20211105201323.GA26765@troutmask.apl.washington.edu> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Rspamd-Queue-Id: 4HmBXP4nnRz557j X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=washington.edu (policy=none); spf=none (mx1.freebsd.org: domain of sgk@troutmask.apl.washington.edu has no SPF policy when checking 128.95.76.21) smtp.mailfrom=sgk@troutmask.apl.washington.edu X-Spamd-Result: default: False [-1.92 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; NEURAL_SPAM_MEDIUM(0.08)[0.083]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; RCVD_COUNT_TWO(0.00)[2]; SUBJECT_HAS_QUESTION(0.00)[]; DMARC_POLICY_SOFTFAIL(0.10)[washington.edu : No valid SPF, No valid DKIM,none] X-ThisMailContainsUnwantedMimeParts: N Why was this committed? commit ac76bc1145dd7f4476e5d982ce8f355f71015713 Author: Dimitry Andric Date: Tue Feb 9 22:06:51 2021 +0100 Fix lib/msun's ctrig_test/test_inf_inputs test case with clang >= 10 This sprinkles a few strategic volatiles in an attempt to defeat clang's optimization interfering with the expected floating-point exception flags. There is nothing, and I mean, nothing strategic about "sprinkling" volatile onto the declaration of "float x, y, h;" These variables are referenced in all floating pointing operations in the file, which means that there are needless reloading of x, y, and h from memory. -- Steve From nobody Fri Nov 5 21:32:26 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 3E3331857F17 for ; Fri, 5 Nov 2021 21:32:34 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HmDHk1LQwz3pQJ; Fri, 5 Nov 2021 21:32:34 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "R3" (verified OK)) (Authenticated sender: dim) by smtp.freebsd.org (Postfix) with ESMTPSA id ECF93AE09; Fri, 5 Nov 2021 21:32:33 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from smtpclient.apple (longrow.home.andric.com [192.168.0.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 8252742CC8; Fri, 5 Nov 2021 22:32:32 +0100 (CET) From: Dimitry Andric Message-Id: <34FEBFCC-1CD6-48CB-BA2A-7A2BBD6B4EA1@FreeBSD.org> Content-Type: multipart/signed; boundary="Apple-Mail=_AAC422C0-B0D2-47AB-86F1-006E4783A159"; protocol="application/pgp-signature"; micalg=pgp-sha1 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: WHY? commit ac76bc1145dd7f4476e5d982ce8f355f71015713 Date: Fri, 5 Nov 2021 22:32:26 +0100 In-Reply-To: <20211105201323.GA26765@troutmask.apl.washington.edu> Cc: freebsd-current@freebsd.org, lwhsu@freebsd.org To: Steve Kargl References: <20211105201323.GA26765@troutmask.apl.washington.edu> X-Mailer: Apple Mail (2.3654.120.0.1.13) X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_AAC422C0-B0D2-47AB-86F1-006E4783A159 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 5 Nov 2021, at 21:13, Steve Kargl = wrote: >=20 > Why was this committed? >=20 > commit ac76bc1145dd7f4476e5d982ce8f355f71015713 > Author: Dimitry Andric > Date: Tue Feb 9 22:06:51 2021 +0100 >=20 > Fix lib/msun's ctrig_test/test_inf_inputs test case with clang >=3D = 10 >=20 > This sprinkles a few strategic volatiles in an attempt to defeat = clang's > optimization interfering with the expected floating-point exception > flags. >=20 > There is nothing, and I mean, nothing strategic about "sprinkling" > volatile onto the declaration of "float x, y, h;" These variables > are referenced in all floating pointing operations in the file, > which means that there are needless reloading of x, y, and h > from memory. There was more context in https://bugs.freebsd.org/244732, but the gist was that with clang >=3D 10, ctanh() and ctanhf() had FE_INVALID set = after calling them with {inf,inf}. The reasons for this were obscure to me at the time, since it regressed with an llvm commit that seemed to have very little to do with floating point. However, in 3b00222f156d we added -fp-exception-behavior=3Dmaytrap to clang's compile flags for lib/msun, for https://bugs.freebsd.org/254911, to force it to use stricter floating point semantics. This turns out to also make the admittedly ugly volatile fixes unnecessary. So I have reverted ac76bc1145dd (minus the ctrig_test.c part) in: = https://cgit.freebsd.org/src/commit/?id=3De2157cd0000f6dbb6465d7a885f2dcfd= 4d3596cb -Dimitry --Apple-Mail=_AAC422C0-B0D2-47AB-86F1-006E4783A159 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.2 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCYYWi6gAKCRCwXqMKLiCW o4FNAJ4lRuHu13EM8+INk+Ao+C4515ONqgCeL8wo/SibHe26krnYJAxXbTeBfpI= =3HIb -----END PGP SIGNATURE----- --Apple-Mail=_AAC422C0-B0D2-47AB-86F1-006E4783A159-- From nobody Fri Nov 5 22:14:46 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 28C0E1840D26 for ; Fri, 5 Nov 2021 22:14:49 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HmFDS6k7dz4YmP; Fri, 5 Nov 2021 22:14:48 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.16.1/8.16.1) with ESMTPS id 1A5MEkxu027224 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 5 Nov 2021 15:14:47 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.16.1/8.16.1/Submit) id 1A5MEkRp027223; Fri, 5 Nov 2021 15:14:46 -0700 (PDT) (envelope-from sgk) Date: Fri, 5 Nov 2021 15:14:46 -0700 From: Steve Kargl To: Dimitry Andric Cc: freebsd-current@freebsd.org, lwhsu@freebsd.org Subject: Re: WHY? commit ac76bc1145dd7f4476e5d982ce8f355f71015713 Message-ID: <20211105221446.GA27181@troutmask.apl.washington.edu> References: <20211105201323.GA26765@troutmask.apl.washington.edu> <34FEBFCC-1CD6-48CB-BA2A-7A2BBD6B4EA1@FreeBSD.org> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <34FEBFCC-1CD6-48CB-BA2A-7A2BBD6B4EA1@FreeBSD.org> X-Rspamd-Queue-Id: 4HmFDS6k7dz4YmP X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Fri, Nov 05, 2021 at 10:32:26PM +0100, Dimitry Andric wrote: > On 5 Nov 2021, at 21:13, Steve Kargl wrote: > > > > Why was this committed? > > > > commit ac76bc1145dd7f4476e5d982ce8f355f71015713 > > Author: Dimitry Andric > > Date: Tue Feb 9 22:06:51 2021 +0100 > > > > Fix lib/msun's ctrig_test/test_inf_inputs test case with clang >= 10 > > > > This sprinkles a few strategic volatiles in an attempt to defeat clang's > > optimization interfering with the expected floating-point exception > > flags. > > > > There is nothing, and I mean, nothing strategic about "sprinkling" > > volatile onto the declaration of "float x, y, h;" These variables > > are referenced in all floating pointing operations in the file, > > which means that there are needless reloading of x, y, and h > > from memory. > > There was more context in https://bugs.freebsd.org/244732, but the gist > was that with clang >= 10, ctanh() and ctanhf() had FE_INVALID set after > calling them with {inf,inf}. The reasons for this were obscure to me at > the time, since it regressed with an llvm commit that seemed to have > very little to do with floating point. > > However, in 3b00222f156d we added -fp-exception-behavior=maytrap to > clang's compile flags for lib/msun, for https://bugs.freebsd.org/254911, > to force it to use stricter floating point semantics. This turns out to > also make the admittedly ugly volatile fixes unnecessary. > > So I have reverted ac76bc1145dd (minus the ctrig_test.c part) in: > https://cgit.freebsd.org/src/commit/?id=e2157cd0000f6dbb6465d7a885f2dcfd4d3596cb > Thanks for the explanation! This would indeed be strange. The evaluation of ctanhf does not invoke ccoshf(z). The relevant section of code from s_ctanh.c (similar code in s_ctanhf.c) is if (ix >= 0x7ff00000) { if ((ix & 0xfffff) | lx) /* x is NaN */ return (CMPLX(nan_mix(x, y), y == 0 ? y : nan_mix(x, y))); SET_HIGH_WORD(x, hx - 0x40000000); /* x = copysign(1, x) */ return (CMPLX(x, copysign(0, isinf(y) ? y : sin(y) * cos(y)))); } The testcase should get to the second return statement. So, either isinf(y) or copysign(0, inf) was raising the exception. -- Steve From nobody Fri Nov 5 23:43:26 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id AD3131847EB0 for ; Fri, 5 Nov 2021 23:43:29 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HmHBm3Pzjz3KgR; Fri, 5 Nov 2021 23:43:28 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.16.1/8.16.1) with ESMTPS id 1A5NhQBd027499 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 5 Nov 2021 16:43:26 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.16.1/8.16.1/Submit) id 1A5NhQOf027498; Fri, 5 Nov 2021 16:43:26 -0700 (PDT) (envelope-from sgk) Date: Fri, 5 Nov 2021 16:43:26 -0700 From: Steve Kargl To: Dimitry Andric Cc: freebsd-current@freebsd.org, lwhsu@freebsd.org Subject: Re: WHY? commit ac76bc1145dd7f4476e5d982ce8f355f71015713 Message-ID: <20211105234326.GA27491@troutmask.apl.washington.edu> References: <20211105201323.GA26765@troutmask.apl.washington.edu> <34FEBFCC-1CD6-48CB-BA2A-7A2BBD6B4EA1@FreeBSD.org> <20211105221446.GA27181@troutmask.apl.washington.edu> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20211105221446.GA27181@troutmask.apl.washington.edu> X-Rspamd-Queue-Id: 4HmHBm3Pzjz3KgR X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=washington.edu (policy=none); spf=none (mx1.freebsd.org: domain of sgk@troutmask.apl.washington.edu has no SPF policy when checking 128.95.76.21) smtp.mailfrom=sgk@troutmask.apl.washington.edu X-Spamd-Result: default: False [-1.00 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; DMARC_POLICY_SOFTFAIL(0.10)[washington.edu : No valid SPF, No valid DKIM,none]; NEURAL_HAM_MEDIUM(-1.00)[-0.997]; 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]; NEURAL_SPAM_SHORT(1.00)[1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; RCVD_TLS_ALL(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On Fri, Nov 05, 2021 at 03:14:46PM -0700, Steve Kargl wrote: > On Fri, Nov 05, 2021 at 10:32:26PM +0100, Dimitry Andric wrote: > > On 5 Nov 2021, at 21:13, Steve Kargl wrote: > > > > > > Why was this committed? > > > > > > commit ac76bc1145dd7f4476e5d982ce8f355f71015713 > > > Author: Dimitry Andric > > > Date: Tue Feb 9 22:06:51 2021 +0100 > > > > > > Fix lib/msun's ctrig_test/test_inf_inputs test case with clang >= 10 > > > > > > This sprinkles a few strategic volatiles in an attempt to defeat clang's > > > optimization interfering with the expected floating-point exception > > > flags. > > > > > > There is nothing, and I mean, nothing strategic about "sprinkling" > > > volatile onto the declaration of "float x, y, h;" These variables > > > are referenced in all floating pointing operations in the file, > > > which means that there are needless reloading of x, y, and h > > > from memory. > > > > There was more context in https://bugs.freebsd.org/244732, but the gist > > was that with clang >= 10, ctanh() and ctanhf() had FE_INVALID set after > > calling them with {inf,inf}. The reasons for this were obscure to me at > > the time, since it regressed with an llvm commit that seemed to have > > very little to do with floating point. > > > > However, in 3b00222f156d we added -fp-exception-behavior=maytrap to > > clang's compile flags for lib/msun, for https://bugs.freebsd.org/254911, > > to force it to use stricter floating point semantics. This turns out to > > also make the admittedly ugly volatile fixes unnecessary. > > > > So I have reverted ac76bc1145dd (minus the ctrig_test.c part) in: > > https://cgit.freebsd.org/src/commit/?id=e2157cd0000f6dbb6465d7a885f2dcfd4d3596cb > > > > Thanks for the explanation! This would indeed be strange. > The evaluation of ctanhf does not invoke ccoshf(z). > > The relevant section of code from s_ctanh.c (similar code in s_ctanhf.c) > is > > if (ix >= 0x7ff00000) { > if ((ix & 0xfffff) | lx) /* x is NaN */ > return (CMPLX(nan_mix(x, y), > y == 0 ? y : nan_mix(x, y))); > SET_HIGH_WORD(x, hx - 0x40000000); /* x = copysign(1, x) */ > return (CMPLX(x, copysign(0, isinf(y) ? y : sin(y) * cos(y)))); > } > > The testcase should get to the second return statement. So, > either isinf(y) or copysign(0, inf) was raising the exception. > I just scanned the llvm report pointed to in the FreeBSD bug report. The llvm report discusses changes in speculative execution. If clang was evaluating isinf(y) and either of sin(y) or cos(y), speculatively, then yes, FE_INVALID will be raised. % tlibm_libm -e cos cosf( 0) = 1. Got no exception. Expected 1 without exception. cosf(-0) = 1. Got no exception. Expected 1 without exception. cosf( inf) = nan. Got FE_INVALID. Expected nan with FE_INVALID. cosf(-inf) = nan. Got FE_INVALID. Expected nan with FE_INVALID. cos( 0) = 1. Got no exception. Expected 1 without exception. cos(-0) = 1. Got no exception. Expected 1 without exception. cos( inf) = nan. Got FE_INVALID. Expected nan with FE_INVALID. cos(-inf) = nan. Got FE_INVALID. Expected nan with FE_INVALID. cosl( 0) = 1. Got no exception. Expected 1 without exception. cosl(-0) = 1. Got no exception. Expected 1 without exception. cosl( inf) = nan. Got FE_INVALID. Expected nan with FE_INVALID. cosl(-inf) = nan. Got FE_INVALID. Expected nan with FE_INVALID. -- Steve From nobody Sat Nov 6 03:55:49 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 6F435184CD52 for ; Sat, 6 Nov 2021 03:55:59 +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) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4HmNp71Tx5z4lhW for ; Sat, 6 Nov 2021 03:55:59 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 1A63tnCW049039 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 6 Nov 2021 05:55:53 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 1A63tnCW049039 Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 1A63tnx0049038; Sat, 6 Nov 2021 05:55:49 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 6 Nov 2021 05:55:49 +0200 From: Konstantin Belousov To: obiwac Cc: freebsd-current@freebsd.org Subject: Re: Potential bug in the dynamic linker? Message-ID: References: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org 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.5 X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on tom.home X-Rspamd-Queue-Id: 4HmNp71Tx5z4lhW X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Fri, Nov 05, 2021 at 06:27:33PM +0100, obiwac wrote: > Let me preface this by saying that I am in no way knowledgeable enough > regarding the FreeBSD dynamic linker to know whether or not this is > infact a bug or intended behaviour. > > This program I'm working on, when compiled for FreeBSD, calls > fdlopen(3) to load a dynamic library from memory. This is how I'm > doing that more specifically: > > // void* lib_bin, size_t lib_len > > int fd = shm_open(SHM_ANON, O_RDWR, 0); > ftruncate(fd, lib_len); > > void* lib_mem = mmap(NULL, lib_len, PROT_WRITE, MAP_SHARED, fd, 0); > memcpy(lib_mem, lib_bin, lib_len); > > munmap(lib_mem, lib_len); > > void* lib = fdlopen(fd, RTLD_LAZY); > close(fd); > > Running this on FreeBSD 13 works fine, FreeBSD 14, however, spits out > this error: > > Cannot fstatfs "" > > Digging around, I find, in libexec/rtld-elf/rtld.c: > > /* > * but first, make sure that environment variables haven't been > * used to circumvent the noexec flag on a filesystem. > */ > if (dangerous_ld_env) { > if (fstatfs(fd, &fs) != 0) { > _rtld_error("Cannot fstatfs \"%s\"", printable_path(path)); > return NULL; > } > if (fs.f_flags & MNT_NOEXEC) { > _rtld_error("Cannot execute objects on %s", fs.f_mntonname); > return NULL; > } > } > > And this is the first thing that seems weird to me. Why is it calling > fstatfs(3) before checking if the file descriptor doesn't necessarily > refer to a file which resides on a physical filesystem? It doesn't say > so on the manpage, but, again, digging around, that's what the error > returned by fstatfs(3), EINVAL, supposedly means. Exactly what is missing from the man page? How do you propose to check for MNT_NOEXEC without querying it with fstatfs()? What could be improved there, IMO, is that fstatfs(2) error is considered fatal, while it is arguably a reason to not check for MNT_NOEXEC. As you pointed out, fd might be not a file. I will commit this change shortly. > > Secondly, why then is dangerous_ld_env even set in the first place? > Well, as of this commit (https://reviews.freebsd.org/D26352): > > ld_dynamic_weak = ld_get_env_var(LD_DYNAMIC_WEAK) == NULL; > > ... > > dangerous_ld_env = libmap_disable || libmap_override != NULL || > ld_library_path != NULL || ld_preload != NULL || > ld_elf_hints_path != NULL || ld_loadfltr || ld_dynamic_weak; This should by !ld_dynamic_weak. I will commit the fix shortly. > > Should this not be > > ld_dynamic_weak = ld_get_env_var(LD_DYNAMIC_WEAK) != NULL; No, this is wrong. You are flipping the meaning of the env variable. > > instead? Or is this actually intended and am I just not understanding > the point of this?