From nobody Mon Mar 24 00:00:43 2025 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 4ZLY9H5QHsz5s0g8; Mon, 24 Mar 2025 00:00:51 +0000 (UTC) (envelope-from salvadore@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZLY9G2CJdz3ctf; Mon, 24 Mar 2025 00:00:50 +0000 (UTC) (envelope-from salvadore@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1742774450; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc; bh=MOt3JUbsSwogspikhDU3md59jyyBtFNCoGPaPtNHItw=; b=eUwo4rlb3DCEgbM+NJtVWcl2YOyAPsH4Xcqu5VJyLKPYr9j03+YndwhYM+l0WVvi+2m7df oko+UYFEfAcCgSq09scTYUoF13VrdIzo0tntWaQhMA4F/KlWgZ37i70JXeLprK8nHzdePP yNzAHaRUWZFsAmH2WtlB0IidRvcebHR1YYyVc+WA/aczWRlT2PAN8OxTq8cMVMxR8hrN81 YVnpfv1Hxg5KjA5usMIauG/9FKLV5NZL2iyt5MR4PM1dTSPQWNW5rRBLDHqlGYy2ijTPxl hkcjfrvzDM/Bss6Wg4zF2epYAN/naQYvfENMWPS5VN0wsnBVS8VhP1wAWQGnwA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1742774450; a=rsa-sha256; cv=none; b=Nb+4KSOLJ8+3Iae5FVx3w4ynQjwYctCI/v47o35CqGrtVLT/G/0c7z8W8DKK9qkDVxF8F6 iGFhdOkBUHWtAnmtF4NCbF7trwxJ9dTW2l462K6VbtpVSWXzBtTugZA7s7ND9BJCfLBcOx sE992+PJP6zpPUOyr4mrhuiVVkVjFmBw70Fn1Vz/zR6ox25QGRp3lD19+QSzhBQ25srYkS 0BRCW0kEzfSf5xCS28+afDsWAvAgOvoFpesls8ht3dDqrDYhs4z4QnPahzp74pVHxHpDIn hPPVa2jQOlnTk6rZdraGX4Fa2uy5OPG+kgPReaDIoefhXo5uai/H7qJg/K3cYw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1742774450; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc; bh=MOt3JUbsSwogspikhDU3md59jyyBtFNCoGPaPtNHItw=; b=XWnvn0bfNoUIUnVR9DSNXjA2Ja6NHZ0IuS4xmBr/n2RFg+J9qls22/9hueEGonEeNTwgx6 2G4JsEIUtupO/3FRVnfkFgjjpqZQwxpHOpC4Kpfngsat9wgL/6ywIfRAUDIueDyCaVW5iU UoJZzrFVVF0y8Re36BQARKluDAFDVbgnIG2hRAbqPQl4vQLJiVT7/2Jkp+AiNVUnnqecv+ H57jeYYxk3pHPXyD0kjYf2jcCROm3+ERN6AtXxIJ/EQQV8BG+xk9p3IiBxEqU3LFx6KpX/ 7qjSJripJodfnoJaSR/gzm3fwBBXlFpaycBI2aM6E1j3MamNRtk25/G1HST8pQ== Received: by freefall.freebsd.org (Postfix, from userid 1472) id C87D77BC4; Mon, 24 Mar 2025 00:00:43 +0000 (UTC) To: freebsd-status-calls@FreeBSD.org Subject: [LAST OFFICIAL REMINDER] Call for 2025Q1 status reports Cc: freebsd-current@FreeBSD.org,freebsd-hackers@FreeBSD.org,devsummit@FreeBSD.org,secretary@asiabsdcon.org Message-Id: <20250324000049.C87D77BC4@freefall.freebsd.org> Date: Mon, 24 Mar 2025 00:00:43 +0000 (UTC) From: Lorenzo Salvadore 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 Dear FreeBSD Community, The deadline for the next FreeBSD Status Report update is March, 31st 2025 for work done since the last round of quarterly reports: January 2025 - March 2025. I would like to remind you that reports are published on a quarterly basis and are usually collected during the last month of each quarter, You are also welcome to submit them even earlier if you want, and the earlier you submit them, the more time we have for reviewing. Status report submissions do not need to be very long. They may be about anything happening in the FreeBSD project and community, and they provide a great way to inform FreeBSD users and developers about work that is underway or has been completed. Report submissions are not limited to committers; anyone doing anything interesting and FreeBSD related can -- and should -- write one! The following methods are available to submit your reports: * submit a review on Phabricator and add the group "status" to the reviewers list. You should put your reports in the directory doc/website/content/en/status/report-2025-01-2025-03/ (create it if it is missing); * submit a pull request at . You should put your reports in the directory doc/website/content/en/status/report-2025-01-2025-03/ (create it if it is missing); * send an email to status-submissions@FreeBSD.org including your report. An AsciiDoc template is available at . We look forward to seeing your 2025Q1 reports! Thanks, Lorenzo Salvadore (on behalf of status@) From nobody Mon Mar 24 08:00:11 2025 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 4ZLlpQ4P4mz5rZLl for ; Mon, 24 Mar 2025 08:00:14 +0000 (UTC) (envelope-from glebius@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 "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZLlpQ3SZCz3St8; Mon, 24 Mar 2025 08:00:14 +0000 (UTC) (envelope-from glebius@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1742803214; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=G3D8eAcuDMKwpH5HmREfXlsgMVGiFwe3LXecA+aarkU=; b=D3VP9v3YPv6R5g5p8DMQ4JpBZ/n9prsZ2R4Ze8iJICXgrRAlHUsK2Nl0JpPwCNl+5G4J6r VVWNQ1Cup5SGYSwOsKJXLtX1x0sEAU9jIQkkWbvYCaSdTaki/GHDo97yGFjRNheIXNsj6u 4TWKzCYtMhe9C682K3AF8T9RlsjY4jz3gVhdEyrsapI5YeyCJfexJNWpMKE7C/I41jadNL amhHc7EsSCGrDetJzZD0rZDgDuUVh9qD/llfQ1rnb6GSF7ezuD8DQQ6rPalJrGBo2sUweE 44ceHgpEXg53u5GI6AGsAysuUCZQ8CtZ9cIcMaPpyBlbeqhCwoW9S0lBNaMhLA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1742803214; a=rsa-sha256; cv=none; b=Z+w4tdvaFzUuK4wLrdimbOI6HEyg5DrntyzRXs3dhx+lXKhFIN2pr7NBckrFDyl9Yr7FOE GBqQENlxOIH/1JjtQKfKv9CqMC4cyypJBBE9oqoaOIaBTQ14uzCFiF3H8c6CLKfvbdSe73 Yw6COIjgAerLy/B0l7BdldY419/gonxHmygWcVBLV15Bh155s74vvtU0vk3rNWhfYg3SFl CRyV+TSclwdNbJgFyHNxzxHqvis9jomeiBn5L9k7DBstC8DNKrv4eWZiIDNNcYa89pSdOd mv1wvIkPlIuH6oqCl1+XcP83S7/Krizn1EM7f5ns2vSmTLjGFJ6mSOaoViEupQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1742803214; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=G3D8eAcuDMKwpH5HmREfXlsgMVGiFwe3LXecA+aarkU=; b=NqT6kvczsfDT2pypn6z7GMwaokb8SVW7eqaVmK2ZvTjVJU4+TD+pTxh3NKdA/7qKMx3b24 sirsb3IE43x7F4XGomP8bWF9eo1dFTPhmYDTlGm5i8QM682rm5V2B2NuWeheYrM0gapkNJ 31kzHyxdlVVJkIEw15YtNMNXwTTm+jn9cxXDc6AoT4Gaa1BKHav+EJc06tc6PL8IGs8O7t IMhK8Xi6TmpZndU426uaogSWajUTZNtg6hV1LRuet+lHcu3/BhIN+ZzAahkB4WSTgFIT6T ek/JzUqf7PB3Xsq76zMJztQp+Riyl2GbAhLqsNtY9WUeFE0NExJWLKYr7cxIIg== Received: from cell.glebi.us (glebi.us [162.251.186.162]) (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) (Authenticated sender: glebius) by smtp.freebsd.org (Postfix) with ESMTPSA id 4ZLlpQ0JFFz3nB; Mon, 24 Mar 2025 08:00:13 +0000 (UTC) (envelope-from glebius@freebsd.org) Date: Mon, 24 Mar 2025 01:00:11 -0700 From: Gleb Smirnoff To: freebsd-current@freebsd.org, src-committers@freebsd.org Subject: March 2025 stabilization week Message-ID: 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 Hi FreeBSD/main users & developers: This is an automated email to inform you that the March 2025 stabilization week started with FreeBSD/main at main-n276073-67c1c4dfd1cc, which was tagged as main-stabweek-2025-Mar. Those who want to participate in the stabilization week are encouraged to update to the above revision/tag and test their systems. The tag main-stabweek-2025-Mar has been published at Gleb Smirnoff's github repo. To connect this repo as an additional remote you need to run: git remote add glebius https://github.com/glebius/FreeBSD Once remote is configured, to checkout the tag run: git fetch glebius --tags git checkout main-stabweek-2025-Mar If you want to use only the official FreeBSD repo, then update to the revision: git pull git checkout 67c1c4dfd1cc Developers are encouraged to avoid pushing new features to FreeBSD/main during the stabilization week, but focus on bugfixes instead. The stabilization week runs up to Friday 18:00 UTC, but if there is consensus that any regressions discovered by participants have been fixed, it will end early. Once that happens, the advisory freeze of FreeBSD/main branch is thawed. -- Gleb Smirnoff From nobody Mon Mar 24 18:32:38 2025 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 4ZM1rH09Wcz5rH3R for ; Mon, 24 Mar 2025 18:32:47 +0000 (UTC) (envelope-from che@bein.link) Received: from mail.bein.link (bein.link [37.252.124.82]) (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 4ZM1rG5PxPz3lDm; Mon, 24 Mar 2025 18:32:46 +0000 (UTC) (envelope-from che@bein.link) Authentication-Results: mx1.freebsd.org; none Received: from [192.168.1.11] (unknown [213.230.114.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.bein.link (Postfix) with ESMTPSA id 62EE623F872; Mon, 24 Mar 2025 18:31:51 +0000 (UTC) Message-ID: Date: Mon, 24 Mar 2025 23:32:38 +0500 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 Thunderbird Subject: Re: March 2025 stabilization week To: Gleb Smirnoff , freebsd-current@freebsd.org, src-committers@freebsd.org References: Content-Language: en-US From: Maxim V Filimonov In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=bein.link; s=mail; t=1742841111; bh=qHla8kndk5NWPruCWt60qggAdBg=; h=Message-ID:Date:MIME-Version:Subject:To:References:From:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=gIGkH7Gmhh672O5o15LhkYT4hAkKO5yeP4GJ17ms+gjW+PRyIJl/e6hm4OWJJ+l7K+en1KML8BWcbCgrtESALnw9csf3LPHITaNBEhqIqifPn9aw1beWYzoxhCSt6ISKX6Khxm1nDi7mJP5UmaPHoHYEmlwKJ4QErhQcSzqqkKk= X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:196752, ipnet:37.252.120.0/21, country:NL] X-Rspamd-Queue-Id: 4ZM1rG5PxPz3lDm X-Spamd-Bar: ---- Just did exactly that. As I've mentioned before on wireless@, my AX201 doesn't want to work with compat.linuxkpi.iwlwifi_disable_11ac=0. It doesn't seem to find the access point and says something in the lines of: Mar 24 22:09:16 hamster kernel: iwlwifi0: ERROR: lkpi_ic_scan_start: hw_scan returned -5 Mar 24 22:09:21 hamster kernel: iwlwifi0: Scan failed! ret -5 That's really the only issue I have here. Will check the tcp issue (panic around tcp_do_segment: sent too much) more thoroughly later On 24.03.2025 13:00, Gleb Smirnoff wrote: > Hi FreeBSD/main users & developers: > > This is an automated email to inform you that the March 2025 stabilization week > started with FreeBSD/main at main-n276073-67c1c4dfd1cc, which was tagged as > main-stabweek-2025-Mar. > > Those who want to participate in the stabilization week are encouraged to > update to the above revision/tag and test their systems. > > The tag main-stabweek-2025-Mar has been published at Gleb Smirnoff's github repo. > To connect this repo as an additional remote you need to run: > > git remote add glebius https://github.com/glebius/FreeBSD > > Once remote is configured, to checkout the tag run: > > git fetch glebius --tags > git checkout main-stabweek-2025-Mar > > If you want to use only the official FreeBSD repo, then update to > the revision: > > git pull > git checkout 67c1c4dfd1cc > > Developers are encouraged to avoid pushing new features to FreeBSD/main during > the stabilization week, but focus on bugfixes instead. The stabilization week > runs up to Friday 18:00 UTC, but if there is consensus that any regressions > discovered by participants have been fixed, it will end early. > > Once that happens, the advisory freeze of FreeBSD/main branch is thawed. > > -- > Gleb Smirnoff > -- wbr, Maxim Filimonov From nobody Mon Mar 24 18:39:16 2025 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 4ZM1zp4Thkz5rHT3 for ; Mon, 24 Mar 2025 18:39:18 +0000 (UTC) (envelope-from che@bein.link) Received: from mail.bein.link (bein.link [37.252.124.82]) (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 4ZM1zp3XRbz3pNL; Mon, 24 Mar 2025 18:39:18 +0000 (UTC) (envelope-from che@bein.link) Authentication-Results: mx1.freebsd.org; none Received: from [192.168.1.11] (unknown [213.230.114.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.bein.link (Postfix) with ESMTPSA id 1F6B223F872; Mon, 24 Mar 2025 18:38:29 +0000 (UTC) Message-ID: Date: Mon, 24 Mar 2025 23:39:16 +0500 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 Thunderbird Subject: Re: March 2025 stabilization week To: Gleb Smirnoff , freebsd-current@freebsd.org, src-committers@freebsd.org References: Content-Language: en-US From: Maxim V Filimonov In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=bein.link; s=mail; t=1742841509; bh=gfnj8CYCjKlhaepATZ8lM0bhUNQ=; h=Message-ID:Date:MIME-Version:Subject:To:References:From:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=eqGM178VElXt6hI4RSBfINv2f9bPfXXYh56scabPcen8+hjmADrdsbDd5mMaWcqkaoCQXv4828cJ5HmwWSJw7gGvGBIDKivpjRY1N7GXO02yc0c7kdm89sCKm5B4Up5Kb4jRr7aBGTB84/rFS+92Ee8ROnn0rvThAd81NzM8z+w= X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:196752, ipnet:37.252.120.0/21, country:NL] X-Rspamd-Queue-Id: 4ZM1zp3XRbz3pNL X-Spamd-Bar: ---- Also, would like to thank Gleb for this awesome initiative! To me, this stabilization week is a great way to see where the development is going, and a great safe way to experience FreeBSD-CURRENT. On 24.03.2025 13:00, Gleb Smirnoff wrote: > Hi FreeBSD/main users & developers: > > This is an automated email to inform you that the March 2025 stabilization week > started with FreeBSD/main at main-n276073-67c1c4dfd1cc, which was tagged as > main-stabweek-2025-Mar. > > Those who want to participate in the stabilization week are encouraged to > update to the above revision/tag and test their systems. > > The tag main-stabweek-2025-Mar has been published at Gleb Smirnoff's github repo. > To connect this repo as an additional remote you need to run: > > git remote add glebius https://github.com/glebius/FreeBSD > > Once remote is configured, to checkout the tag run: > > git fetch glebius --tags > git checkout main-stabweek-2025-Mar > > If you want to use only the official FreeBSD repo, then update to > the revision: > > git pull > git checkout 67c1c4dfd1cc > > Developers are encouraged to avoid pushing new features to FreeBSD/main during > the stabilization week, but focus on bugfixes instead. The stabilization week > runs up to Friday 18:00 UTC, but if there is consensus that any regressions > discovered by participants have been fixed, it will end early. > > Once that happens, the advisory freeze of FreeBSD/main branch is thawed. > > -- > Gleb Smirnoff > -- wbr, Maxim Filimonov From nobody Mon Mar 24 21:44:12 2025 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 4ZM65f5HdTz5rVwd for ; Mon, 24 Mar 2025 21:44:38 +0000 (UTC) (envelope-from void@f-m.fm) Received: from fout-a7-smtp.messagingengine.com (fout-a7-smtp.messagingengine.com [103.168.172.150]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZM65d6pVFz3xKd; Mon, 24 Mar 2025 21:44:37 +0000 (UTC) (envelope-from void@f-m.fm) Authentication-Results: mx1.freebsd.org; none Received: from phl-compute-07.internal (phl-compute-07.phl.internal [10.202.2.47]) by mailfout.phl.internal (Postfix) with ESMTP id 4C8621384913; Mon, 24 Mar 2025 17:44:33 -0400 (EDT) Received: from phl-imap-04 ([10.202.2.82]) by phl-compute-07.internal (MEProxy); Mon, 24 Mar 2025 17:44:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc:cc :content-transfer-encoding:content-type:content-type:date:date :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm2; t=1742852673; x=1742939073; bh=/9gbHDL+QfwzwpIwGpEWTVcghR8uy37unQAjBvI0WRU=; b= QWLalWjajeq6x3ogqzJQr93thLiv2AGiz6uFnJuB3z+6mk+sYvxJZbiFCg4m4moD Z9yiaDMkAjMZ8lsz51UzkuD4kH9cWmQS9xzdonUr+h8ltLFG1LPkZa/X/V+n4A1k zReGoJuGzYo+QuII8X0UgII9KeuXYw+QD9n9TA5gckYYn6og/f6wQRn0Be3VAzGG 55S3mcCbtirGMIbcLYqQ7koGNdGDUqZsSSjKamIjez8WtNZzp/mEqsF/C28LYcDP d0K9QPbDItDflIs4oD/ljoUd21uWgIzAKRl5XcV6WGL0YHHcewptTvoqfwXfOhgV g0Q/QR/y6m3udQ6pjBx8pA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1742852673; x= 1742939073; bh=/9gbHDL+QfwzwpIwGpEWTVcghR8uy37unQAjBvI0WRU=; b=X gai8SKhQBGD4bPTUQ+iqM0FAeo2BQGMIx+d/vNxIZOqjFb5v6Z7Cqd3KgTqy40KC Z4LfG7LOqiIcLzX8kMSszDFUfTZfrOJ7/LFmlXhev1qIYPlNY6GK3LwKPL5FNSyx MScbmeyu2aAjURZ/02kZrw4LbrBthYts+BXsVZIHBAwP3QSq1i8l9CjykvcB/U4Q 2E1q4fAk/INN6XX6hgR5/BYEDInZUPVwNOek1xUrtROA/p0WCHAPC87k00wtxw6P BaW1OgPb7GHA/LmjGBffoHjy3ep4K8tLyaIKRpphLIHnVavbaGgxfNn1sI229yzJ nrK7TLkfZRkLxMQ/XONVw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdduiedtkeekucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggv pdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucenucfjughrpefogg ffhffvvefkjghfufgtgfesthejredtredttdenucfhrhhomhepvhhoihguuceovhhoihgu sehfqdhmrdhfmheqnecuggftrfgrthhtvghrnhepgfejhffftdfgvdfgjeffleeiffeffe fhteehjeduhefgfedufedtvdeffeelvddvnecuffhomhgrihhnpehfrhgvvggsshgurdho rhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepvh hoihgusehfqdhmrdhfmhdpnhgspghrtghpthhtohepvddpmhhouggvpehsmhhtphhouhht pdhrtghpthhtohepfhhrvggvsghsugdqtghurhhrvghnthesfhhrvggvsghsugdrohhrgh dprhgtphhtthhopehglhgvsghiuhhssehfrhgvvggsshgurdhorhhg X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id 1A86A2E60088; Mon, 24 Mar 2025 17:44:33 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface 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-ThreadId: Tf3b20eef81cdd16b Date: Mon, 24 Mar 2025 21:44:12 +0000 From: void To: freebsd-current Cc: "Gleb Smirnoff" Message-Id: <6bdad901-fef6-4659-9212-562b579ac19a@app.fastmail.com> In-Reply-To: References: Subject: Re: March 2025 stabilization week Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:209242, ipnet:103.168.172.0/24, country:US] X-Rspamd-Queue-Id: 4ZM65d6pVFz3xKd X-Spamd-Bar: ---- Hi Gleb, On Mon, 24 Mar 2025, at 08:00, Gleb Smirnoff wrote: > Hi FreeBSD/main users & developers: > > This is an automated email to inform you that the March 2025 stabilization week > started with FreeBSD/main at main-n276073-67c1c4dfd1cc, which was tagged as > main-stabweek-2025-Mar. >snip< Is the make installworld problem reported in https://lists.freebsd.org/archives/freebsd-current/2025-March/007235.html still present? ty -- From nobody Mon Mar 24 23:04:18 2025 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 4ZM7sq1Pzvz5rbMv for ; Mon, 24 Mar 2025 23:04:31 +0000 (UTC) (envelope-from olivier@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZM7sq095Gz3tCQ for ; Mon, 24 Mar 2025 23:04:31 +0000 (UTC) (envelope-from olivier@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1742857471; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=bM02LJCY2633z5UXvJtJPRYIKWIquuQWcPr6jCjWxrc=; b=VVUTUwpb6P4WETj2vr1SQ2E+kZ3To/lwdWzq393BNBehVHX4WI43FSjfQCbSyUE+fWbmc0 g04tgh8I81sMrX81IM717t0BiNw3RhQFN8g8XDHHAWOSOJwFnx1TWc4jAo6CArgX9uHqfn ItGA79Ht1sBoReFxRMtsV9xOXN+ajTDdVdMJiL0Wrkvk4q4ZuFsrOnNlzJsJOs+wumnFqS fCPwWW2oCN0YJulYBa1v9yLmBPTrSjWXKzhuBgxoTv4q7fBhaQXQiLmxRUpOAIZlI0dHgj j1BXR/TQDNlSa+qkNNAbdkFgP/jmLYe0FndP2mCwidXogsvGyqv2oc2gZcGCbg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1742857471; a=rsa-sha256; cv=none; b=JVUK8Fj1ssJdyBEDwP+khhMu0bozoeukQXEmyZIpA4VzjaeJF+0nvwe1UqQk3NOJqxELQ9 xUhtYA50tmXfxVShTd4x/j6QDWvmH510JKPja+U7IvESJ03JQpJghmApGlv/KHMX8NgUWa vI++mViE9Q3egx9B2M5htevi6s0woY9ProTFiTXm6Ydc7dgtdHDdhUwft8z4VIEMPlPPPk DkX1rCxrm3T0KBNxoAxZtSYrV6y/3Kkh8JhZVbBzTcTPLRzmd6aFvc3saSu7f1tYoVwD7y C4XeZv8wb6HRwDxWEmSCXp3ir99ufRHHp7/ITYlhi1qHJw6XxeV1PaD0J8TnAQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1742857471; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=bM02LJCY2633z5UXvJtJPRYIKWIquuQWcPr6jCjWxrc=; b=Skcr9uL0vAoTsrfQ+Fl8EVWNvjD48OffbuGK8qSa/po8Rt4ScadR8/aYViBnkpdXf1SL03 wPKrZK3Ktt0qgBuV0nJvXf1ZBxCwbhGo2od/9LvrKBD1z9OJEjUsZ7PSf8Zin9/wRZoWRm HI9RPts0Glss8c2/MzT8UjhR9a6CAEQuTttiq/jim1p3y4TDyDIf/K4bl6Hv3GkdmGNKYF x8vHtKRSjD9ArLuyQ7/huHJIWyJu+/fVw2cnDqYBhP69cTajXDdm3WyGn49iq8Sv23e0Im TQRrLfclf2IUf7X5QiC6ZzX+hUE2xuTKYtHwAhOVC7VHpcu6T1oyCnC2ydqHjA== Received: from mail-qv1-f48.google.com (mail-qv1-f48.google.com [209.85.219.48]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) (Authenticated sender: olivier/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4ZM7sp6Gl6zNrJ for ; Mon, 24 Mar 2025 23:04:30 +0000 (UTC) (envelope-from olivier@freebsd.org) Received: by mail-qv1-f48.google.com with SMTP id 6a1803df08f44-6e900a7ce55so74946296d6.3 for ; Mon, 24 Mar 2025 16:04:30 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCUczthoGXeF6GomkNXIt/Hu1TBb3nzWGZlpLD9oDu0HQqgIkoy8yT0tEZ68tu//vOT+goTVWqZxYFjArOQHl08=@freebsd.org X-Gm-Message-State: AOJu0YzScTUP8sTkB3ANTwAnNq2lo7RyzlmBb47csqwhZxsfygwjheoo WOEKT/D6n0WrI/+wu2OMHq/Pdl3b1G1RXdlVScilStfdYGAiIaYacemfk+ZAZbCalv+Z8t2n05M P2EPX0sauVDK7GDTjakCaFopftA0= X-Google-Smtp-Source: AGHT+IFRH3yxmX33APSxSvRlAoqOXgXyUtpfvShFaoLBtkQUXWYno3t4Py6+COLCVAyxqruPZNbmY6CXx8k+AmXZOKk= X-Received: by 2002:a05:6214:19cd:b0:6d8:9062:6616 with SMTP id 6a1803df08f44-6eb3f2ba60fmr225712936d6.7.1742857470353; Mon, 24 Mar 2025 16:04: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 References: <91d1dd47-c061-47bb-b149-197fcc78f000@app.fastmail.com> In-Reply-To: <91d1dd47-c061-47bb-b149-197fcc78f000@app.fastmail.com> From: =?UTF-8?Q?Olivier_Cochard=2DLabb=C3=A9?= Date: Tue, 25 Mar 2025 00:04:18 +0100 X-Gmail-Original-Message-ID: X-Gm-Features: AQ5f1Jq4h5acWIbPMrDhLHT004Pmz0kWxcoDDm7gQhHS_OnKUzB5790mblAofyQ Message-ID: Subject: Re: make installworld fails due to missing libmd.so.6 or libmd.so.7 To: Dave Cottlehuber Cc: Matthias Apitz , "Herbert J. Skuhra" , freebsd-current Content-Type: multipart/alternative; boundary="0000000000006a33fd06311ea0c8" --0000000000006a33fd06311ea0c8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Mar 23, 2025 at 8:41=E2=80=AFAM Dave Cottlehuber wrote: > > I'm seeing this also using beinstall.sh from 14.2-RELEASE -> 15.0-CURRENT > via ro-nfs. > > Guess its not possible to do a from-source upgrade atm. > > I=E2=80=99m using this trick on my side: LD_PRELOAD=3D/usr/obj/usr/src/amd64.amd64/lib/libmd/libmd.so.7 tools/build/beinstall.sh But the system was a few "old weeks" current only: I didn=E2=80=99t try tha= t from a -release. Regards, Olivier --0000000000006a33fd06311ea0c8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On = Sun, Mar 23, 2025 at 8:41=E2=80=AFAM Dave Cottlehuber <dch@skunkwerks.at> wrote:

I'm seeing this also using beinstall.sh from 14.2-RELEASE -> 15.0-CU= RRENT via ro-nfs.

Guess its not possible to do a from-source upgrade atm.

I=E2=80=99m using this trick on my side:

LD_PRELOAD=3D/usr/obj/usr/= src/amd64.amd64/lib/libmd/libmd.so.7 tools/build/beinstall.sh
=C2=A0
= But the system was a few "old weeks" current only: I didn=E2=80= =99t try that from a -release.

Regards,
Olivier
--0000000000006a33fd06311ea0c8-- From nobody Tue Mar 25 04:55:33 2025 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 4ZMHfx1354z5s0GY for ; Tue, 25 Mar 2025 04:55:37 +0000 (UTC) (envelope-from glebius@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 "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZMHfw6Vncz49yG; Tue, 25 Mar 2025 04:55:36 +0000 (UTC) (envelope-from glebius@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1742878537; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=2jKGe5o9vhTXUEEMxEDrZgko8GGN0YXLfd0dgRUIR3A=; b=aQUZbhkDUzvwNIcXxFg6HXR4v08REu8GbU2mb2MuKHv/ZkL2LMSN6DbdtQm2ONniE4qzJg on7OW1S+agBb6ChTxkpdE1cX+tISwizehaYlEJgX9UzDvkOt3CZLul/0tF68samc3jCQBr muh5yPF6JNxc6lN0mcLl+Yk4M6Y6QCEoVmmgnYjk/ZS4MRfuo0HQInmqylSEKVQOenqS7O IsVdUWYoAg48YPlyatV5bmXuQGwqPWxvkU0Y+sCkgHdIG0RCHNxDtJ8tEh/89rvMcD2u4T UPIYLDi8deIrtd7wY+uNPmNFPPqn/t/aTm43gF8rmYzURWlUWVAuNR1aXz62Cw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1742878536; a=rsa-sha256; cv=none; b=HwIlTIdFB0v8UaLlNGBE0HtU87Md03hjHi6UIC1P1j+BiNopKnWbl2cnGPgxQxxpvgKU3n Nj9eJUUOPBu85Klv7+yP7Y5+gpXwpgsT01iExVSAFjyH/BiwJ/seRX4cDkdxp5mUwAQDGy BN+sDdrMdlH8Eswz2P11hfcdTlUUNNmcFwDN3M/xrTd2GxjcBr4UjEHqBrWiLa0kVFpvCt nDkgFWB4rAWj6gVi9UyBVBSLA8egaiePAGk313saWC1w9iLSMAAyu/8fXpqIOID8ZPoQdl pR+kMVbw5zRDXaS63uuwMLbNOGSESdqgPLJrUPxrdqxk1DdHRKvJvUxMH/3exg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1742878536; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=2jKGe5o9vhTXUEEMxEDrZgko8GGN0YXLfd0dgRUIR3A=; b=nhgBTRHthTUvcc7uQauKsTwfez6FMX6ZaOlSn/bZvF+ALY8ny3zxnA4XIXguXLmoCVP3ml EMeuNxoL4XLgskvi/NFK6t6Z5DZM2IxAkAlPSNSoeOO5J0bkAaH8vaWaUXx5dDbToe/PHd yYI1v7YvBSJUoJv1A/hQYQ5/6RrG+cdNFaxke5YbMdbUQOjpFwb4Es+pE6MLtTN6JKB2zo IXajPiXkdRlt8dc8fLwim9MZa6pnf5e61exoTDECq6PEM+ccZTpLUBHT2xyGlDeBphsM7/ FgS8Wsp+4zoeTiGcHnXkQcFqF/veJ7dHb/Yg3QPBPEzmW27OpEqgNAqbJMf1jw== Received: from cell.glebi.us (glebi.us [162.251.186.162]) (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) (Authenticated sender: glebius) by smtp.freebsd.org (Postfix) with ESMTPSA id 4ZMHfw37vhznFg; Tue, 25 Mar 2025 04:55:36 +0000 (UTC) (envelope-from glebius@freebsd.org) Date: Mon, 24 Mar 2025 21:55:33 -0700 From: Gleb Smirnoff To: void Cc: freebsd-current Subject: Re: March 2025 stabilization week Message-ID: References: <6bdad901-fef6-4659-9212-562b579ac19a@app.fastmail.com> 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: <6bdad901-fef6-4659-9212-562b579ac19a@app.fastmail.com> On Mon, Mar 24, 2025 at 09:44:12PM +0000, void wrote: v> > This is an automated email to inform you that the March 2025 stabilization week v> > started with FreeBSD/main at main-n276073-67c1c4dfd1cc, which was tagged as v> > main-stabweek-2025-Mar. v> v> Is the make installworld problem reported in https://lists.freebsd.org/archives/freebsd-current/2025-March/007235.html still present? I don't know about the 14.2 -> 15.0 upgrade path. The report sounds like a problem that definitely needs to be fixed. But it is out of scope of stabilizatoin weeks, which track CURRENT users. However, given that a STABLE user who wants to switch to CURRENT needs this problem fixed, I understand why you ask here :) We will look at this and I will update you with more info. -- Gleb Smirnoff From nobody Tue Mar 25 09:39:56 2025 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 4ZMPz74BzGz5sHMP for ; Tue, 25 Mar 2025 09:40:03 +0000 (UTC) (envelope-from olce@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 "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZMPz71PDgz44Y1; Tue, 25 Mar 2025 09:40:03 +0000 (UTC) (envelope-from olce@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1742895603; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=GmJvwdxRB8VilCoGzW399KuApSYpAdOPyue9BG57z+4=; b=hzqyblePC8upLQI2NkjEU6avbu5TFneBsu7/2culaYIskfMGyrybuoubb30XDKegroyDfv hvI22mXWr7xxCysEUN4qwudSNSTiffUB+vpRPLiTfF4+cus87gRLuZBxTAOvRfm6rr8bji a01ny4fDhfgi5liF45N43uvSdD1/SSRJ2B8guqkNFpqOXC4erzraHpZ21r9t89p9PSPdnT OamkQata3D+0uI7ofR5L5GjwhjU1E8DExPbQQWxcJuZLlADKqQHYGBWad1+xs+BlMFWC0Q BcWZRKgIL794AugemOH9CP68K1BAXfZO/2XnUaQTDVAbVux4GLh7Jufk1hf9ow== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1742895603; a=rsa-sha256; cv=none; b=fj4QfUk5xPpkkIWVcdfj3mU7RRYIdMP1DOcMjXZcuQv/cSAl/BEW/3m30yzgb1gSZ88dmx M/u1XdSZp7bMYG0jJbkLkD0n1s/jlZo6ltMfqteLV3dyVU/k+nqm9m/ZU2kMoabzBXsXxy psHRoYSRn2bE0Lkbd86x2LuuzfMLz6I9JuFacEB7og07UjYzzc5mzmg0ZQ5rMalSbbPxIv O0jye4E1Amy5pgRNsxh6cCEGGtBt0O1s1NydLEKvOZwA1Usa0fpMXnjOQZ801FxPxry8Xb wWyHkynMtKTv6OPACuzaXB9YJW1ZUDYiU668g0lFsD0lmxA+JliQ8P4LkMrVmQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1742895603; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=GmJvwdxRB8VilCoGzW399KuApSYpAdOPyue9BG57z+4=; b=DSJWiW5aKe8BAFhzoY8jsdu6UqDuVSXFxXYGFEV2/A8CN9U3lOl+IzfGSV8kE/FqG5ahDl qfBbqqFuK//wC/PEz3xmMIpq6jJT3WBx4HZ1LOPbXD9AwZ+8QpDCKHnj5OAzHLG1CSvP3D W0ayvUoaUVZYesvRpdRg9ZYzlxvVH3eZM6sGCPHDkKFwdxNBOp/xgvhPBesN3herM/jLi3 b1j7vrPf/Wqb9kL/6ZBJaiO5rWVeIlMwQY12C7VWyHLDH3A0C+z6gHdbi2Ci9fcOx8+lig hPLXHefqBGLgQ8RwpiTWL5vid2Wj2o2U7MtRDUhHe70vyUSXZyAxUpOmJ2BC1Q== Received: from ravel.localnet (aclermont-ferrand-653-1-222-123.w90-14.abo.wanadoo.fr [90.14.66.123]) (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) (Authenticated sender: olce/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4ZMPz64kthztgn; Tue, 25 Mar 2025 09:40:02 +0000 (UTC) (envelope-from olce@freebsd.org) From: Olivier Certner To: freebsd-current@freebsd.org, src-committers@freebsd.org, Gleb Smirnoff Subject: Re: March 2025 stabilization week Date: Tue, 25 Mar 2025 10:39:56 +0100 Message-ID: <6881633.Qb2xPn7ZBO@ravel> In-Reply-To: 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: multipart/signed; boundary="nextPart174336309.JjRJgqNtZ3"; micalg="pgp-sha384"; protocol="application/pgp-signature" --nextPart174336309.JjRJgqNtZ3 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="UTF-8"; protected-headers="v1" From: Olivier Certner Subject: Re: March 2025 stabilization week Date: Tue, 25 Mar 2025 10:39:56 +0100 Message-ID: <6881633.Qb2xPn7ZBO@ravel> In-Reply-To: References: MIME-Version: 1.0 Hi, I'd like to recommend cherry picking commit 718d1928f874 on top of the stabweek tag for people using DRM kmod's amdgpu driver. It fixes longstanding bug PR 277476 (GUI freezes after some time, due to memory fragmentation) for DRM kmod 5.15 or higher (5.10 is unaffected). The patch has been reviewed and battle-tested by multiple people on different hardware for weeks to months, so we expect no regressions of any sort. That said, as the current plan is to MFC this change to stable/14 before releng/14.3, more testing, with possibly different hardware, is always welcome and would be great. If you test it, please report about your experience (even if it's just to say "it works", or "I don't see any difference") and your GPU. Thanks and regards. -- Olivier Certner --nextPart174336309.JjRJgqNtZ3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCQAdFiEEmNCxHjkosai0LYIujKEwQJceJicFAmfieewACgkQjKEwQJce Jif33g/+JJF5PA4qUWvdu950khN3HQ3GBmFMCddeSm7NnUpGbgpFpILgausmiAHn zsr7E0W8YT8rd1OrvKBELRcZdODDiP1AtmfP4oB1NHfSmQQAMeC95FntN5lbQlxk ouayYJunO6mlH8/PeiN7hjKAf5k8vFWnepfeXa10NFDzCrVhCHz2Wf5Mz43kbk3Q N0oKKPMlTfA5MicKBtjbGszXZiab5hx2EKgaPLFWATrPFyyGRUF0iKpkFry6pM5P XVXpXAb+6R9XxJvfv3MI5KZdXVbcJtLTxvL9m2jcm06fUpJNbrUdKxy15qo2XbXF Ahj5Sdnm0niDNe3+qLQECfxCzHUqakCgPK8p1dSr1iYy/vqyOxpIyDcHNPfBYROk sow8qwy2GBeWDF+pXWkjqndSlGItFBqbU846DPRRNK/KYOY15SlIs9UnIDzo6ipF t5OzPcCakOqhSix6Rb28ypRmjxaXCBOwWvvqh7GUVjS9AwLwV0CWpTmoGpxClPDQ KAR2n7NnJm6BZF4TurMrgnlLqPJBTJ5WlM9JSp6YkkVRGqyFTCqOGoEYcniK/ANo URm5GEHdsXbl9cELueBT9lwiP7aL16pItp5EBR9j4W57SIk0ymuinhJdZ4JZqozM whH7gQo+ficcEPH0njD8VaQUSCZHYUCXZ6Y+cAz3MLfRNPBR18U= =nW7q -----END PGP SIGNATURE----- --nextPart174336309.JjRJgqNtZ3-- From nobody Tue Mar 25 10:03:47 2025 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 4ZMQVb26t1z5sJhL for ; Tue, 25 Mar 2025 10:03:51 +0000 (UTC) (envelope-from void@f-m.fm) Received: from fhigh-a1-smtp.messagingengine.com (fhigh-a1-smtp.messagingengine.com [103.168.172.152]) (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 4ZMQVZ6p94z48mB; Tue, 25 Mar 2025 10:03:50 +0000 (UTC) (envelope-from void@f-m.fm) Authentication-Results: mx1.freebsd.org; none Received: from phl-compute-03.internal (phl-compute-03.phl.internal [10.202.2.43]) by mailfhigh.phl.internal (Postfix) with ESMTP id 56B0F1140298; Tue, 25 Mar 2025 06:03:49 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-03.internal (MEProxy); Tue, 25 Mar 2025 06:03:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc:cc :content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm2; t=1742897029; x=1742983429; bh=7+vsflpQ7+ PwlyFvgtzc7VqyPNUWwdZVaIwjPOSEqn8=; b=g8GE2UolDMk+URFqjx0AufiO2W 8tZDiDWnVy1Ob8lqltfpr7APJlBDmH0rBdAVAcK+9lC3GEkUW/J5uPISqBEyKxnu XKn+lEhkb/MjuQ+mevXBqu4bXrrKK5ySZxuebrsQ/+35qDKwe2uHLBS4y8yvVUe9 aY31Bxl/0PSIE2caPtDGVmoV56fkXE/XCXRLiYxMti60D4nrH006wBrs4iFuldwN +iIREw4Vfiof7TfUSAEi40mebY2viA2YLWb1G3wKrY+zAYvnwW0VPD28Lb+n215N PUvfW/QY+ufWztRPGKtFJrwyUoa5ANtvmzg8UYvg8FFiJPbkdlciSImRKp/Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t= 1742897029; x=1742983429; bh=7+vsflpQ7+PwlyFvgtzc7VqyPNUWwdZVaIw jPOSEqn8=; b=Sb5LU71D2pCsn5mUL1e3+Wn4OgPwatdZoCwaRXtEuvVIGj5ZPG2 WO3setadtHVwoRY7uM1XsJshfzPndjR46moP6+3q7raEhDYILGHCpTtS3vGvc7Is pHlRPntRO/M5rq5AuD90d35lq8Y+608vttaO2UXAgnXx5s/WxuwGHI4ykON9Ecfn y0HFaHfiKJlb+fKsoOqccTWrJJHvMsQDArw+rcrVSkvgA6zdgb21n96LvqHc+Z0o A8a+7l3729WMLM+C8CoxjdadBfHLiaf4Yc2+jhy3bZCdC2w6Sx7KkrEwzM3lbzRQ Nj9J0PJpTf8WT+ubjPt7shQu1lxJ73VeWJA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdduiedvfeeiucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggv pdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucenucfjughrpeffhf fvvefukfhfgggtuggjsehttdertddttddvnecuhfhrohhmpehvohhiugcuoehvohhiuges fhdqmhdrfhhmqeenucggtffrrghtthgvrhhnpeeggfehhfejjeekteeufeehfefhgeejgf eliedvhedvffffhffgiedtvddtgfehueenucffohhmrghinhepfhhrvggvsghsugdrohhr ghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehvoh hiugesfhdqmhdrfhhmpdhnsggprhgtphhtthhopedvpdhmohguvgepshhmthhpohhuthdp rhgtphhtthhopehglhgvsghiuhhssehfrhgvvggsshgurdhorhhgpdhrtghpthhtohepfh hrvggvsghsugdqtghurhhrvghnthesfhhrvggvsghsugdrohhrgh X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 25 Mar 2025 06:03:48 -0400 (EDT) Date: Tue, 25 Mar 2025 10:03:47 +0000 From: void To: Gleb Smirnoff Cc: freebsd-current Subject: Re: March 2025 stabilization week Message-ID: Mail-Followup-To: Gleb Smirnoff , freebsd-current References: <6bdad901-fef6-4659-9212-562b579ac19a@app.fastmail.com> 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; format=flowed Content-Disposition: inline In-Reply-To: X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:209242, ipnet:103.168.172.0/24, country:US] X-Rspamd-Queue-Id: 4ZMQVZ6p94z48mB X-Spamd-Bar: ---- Hi Gleb, On Mon, Mar 24, 2025 at 09:55:33PM -0700, Gleb Smirnoff wrote: >I don't know about the 14.2 -> 15.0 upgrade path. The report sounds like a >problem that definitely needs to be fixed. But it is out of scope of >stabilizatoin weeks, which track CURRENT users. However, given that a STABLE >user who wants to switch to CURRENT needs this problem fixed, I understand why >you ask here :) I should have mentioned my exact context in my first email. sorry about that :( In the thread starting from https://lists.freebsd.org/archives/freebsd-current/2025-March/007168.html the issue (if i'm reading correctly) seems to also affect earlier versions of -current. My context is at version main-n273082-525a177c1657 with another box at main-n273486-88dd0550920c ty -- From nobody Tue Mar 25 10:04:16 2025 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 4ZMQWC6Q5Nz5sJqD for ; Tue, 25 Mar 2025 10:04:23 +0000 (UTC) (envelope-from rum1cro@yandex.ru) Received: from forward501d.mail.yandex.net (forward501d.mail.yandex.net [IPv6:2a02:6b8:c41:1300:1:45:d181:d501]) (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 4ZMQW93xwWz49HB; Tue, 25 Mar 2025 10:04:21 +0000 (UTC) (envelope-from rum1cro@yandex.ru) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yandex.ru header.s=mail header.b=o9cfLK43; dmarc=pass (policy=none) header.from=yandex.ru; spf=pass (mx1.freebsd.org: domain of rum1cro@yandex.ru designates 2a02:6b8:c41:1300:1:45:d181:d501 as permitted sender) smtp.mailfrom=rum1cro@yandex.ru Received: from mail-nwsmtp-mxback-production-main-81.klg.yp-c.yandex.net (mail-nwsmtp-mxback-production-main-81.klg.yp-c.yandex.net [IPv6:2a02:6b8:c42:6c2d:0:640:8d15:0]) by forward501d.mail.yandex.net (Yandex) with ESMTPS id 3DBB7611F3; Tue, 25 Mar 2025 13:04:17 +0300 (MSK) Received: from mail.yandex.ru (2a02:6b8:c42:d42f:0:640:476e:0 [2a02:6b8:c42:d42f:0:640:476e:0]) by mail-nwsmtp-mxback-production-main-81.klg.yp-c.yandex.net (mxback/Yandex) with HTTPS id E4MxH6BLqSw0-ggXfQiMk; Tue, 25 Mar 2025 13:04:16 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1742897056; bh=qa5ArnHGy8xrtzUSGhyIg6da3Bh0d5n5yjTAw4FlSYw=; h=Message-Id:References:Date:Subject:To:In-Reply-To:From; b=o9cfLK43M8iSyUMP7WdAuxZAK+K/bCd6ABVJh2vbOxmZO8BfqJlW7vHK7uHov5iX8 3l9yP82ulNYcbLukvf404QAre74VW3qhMR571zqYQuNSC2M6Szfp1abZF31GVuDSwb R3aSsP0iO06dE3FFGFfeFmTTg6EDiz0zrMgcaocg= Received: by mail-sendbernar-production-main-69.klg.yp-c.yandex.net with HTTP; Tue, 25 Mar 2025 13:04:16 +0300 From: Ilya A. Arkhipov To: Gleb Smirnoff , freebsd-current Current In-Reply-To: References: Subject: Re: March 2025 stabilization week 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-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Tue, 25 Mar 2025 13:04:16 +0300 Message-Id: <336431742896931@mail.yandex.ru> Content-Transfer-Encoding: base64 Content-Type: text/html; charset=utf-8 X-Spamd-Result: default: False [2.29 / 15.00]; NEURAL_SPAM_LONG(1.00)[1.000]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; NEURAL_SPAM_SHORT(0.99)[0.991]; DMARC_POLICY_ALLOW(-0.50)[yandex.ru,none]; R_DKIM_ALLOW(-0.20)[yandex.ru:s=mail]; R_SPF_ALLOW(-0.20)[+ip6:2a02:6b8:c00::/40]; MIME_HTML_ONLY(0.20)[]; RCVD_IN_DNSWL_LOW(-0.10)[2a02:6b8:c41:1300:1:45:d181:d501:from]; MIME_BASE64_TEXT(0.10)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:~]; FREEMAIL_ENVFROM(0.00)[yandex.ru]; ASN(0.00)[asn:13238, ipnet:2a02:6b8::/32, country:RU]; DWL_DNSWL_NONE(0.00)[yandex.ru:dkim]; MID_RHS_MATCH_FROMTLD(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; FREEMAIL_FROM(0.00)[yandex.ru]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[yandex.ru:+] X-Rspamd-Queue-Id: 4ZMQW93xwWz49HB X-Spamd-Bar: ++ PGRpdj4tIHNyYy1jb21taXR0ZXJzQDwvZGl2PjxkaXY+wqA8L2Rpdj48ZGl2PtCa0L7QvNGDOiBm cmVlYnNkLWN1cnJlbnRAZnJlZWJzZC5vcmcgKGZyZWVic2QtY3VycmVudEBmcmVlYnNkLm9yZyks IHNyYy1jb21taXR0ZXJzQGZyZWVic2Qub3JnIChzcmMtY29tbWl0dGVyc0BmcmVlYnNkLm9yZyk7 PC9kaXY+PGRpdj7QotC10LzQsDogTWFyY2ggMjAyNSBzdGFiaWxpemF0aW9uIHdlZWs7PC9kaXY+ PGRpdj4yNC4wMy4yMDI1LCAxMTowMCwgIkdsZWIgU21pcm5vZmYiICZsdDtnbGViaXVzQGZyZWVi c2Qub3JnJmd0Ozo8L2Rpdj48YmxvY2txdW90ZT48cD7CoMKgSGkgRnJlZUJTRC9tYWluIHVzZXJz ICZhbXA7IGRldmVsb3BlcnM6PGJyIC8+PGJyIC8+VGhpcyBpcyBhbiBhdXRvbWF0ZWQgZW1haWwg dG8gaW5mb3JtIHlvdSB0aGF0IHRoZSBNYXJjaCAyMDI1IHN0YWJpbGl6YXRpb24gd2VlazxiciAv PnN0YXJ0ZWQgd2l0aCBGcmVlQlNEL21haW4gYXQgbWFpbi1uMjc2MDczLTY3YzFjNGRmZDFjYywg d2hpY2ggd2FzIHRhZ2dlZCBhczxiciAvPm1haW4tc3RhYndlZWstMjAyNS1NYXIuPGJyIC8+PGJy IC8+VGhvc2Ugd2hvIHdhbnQgdG8gcGFydGljaXBhdGUgaW4gdGhlIHN0YWJpbGl6YXRpb24gd2Vl ayBhcmUgZW5jb3VyYWdlZCB0bzxiciAvPnVwZGF0ZSB0byB0aGUgYWJvdmUgcmV2aXNpb24vdGFn IGFuZCB0ZXN0IHRoZWlyIHN5c3RlbXMuPGJyIC8+PGJyIC8+VGhlIHRhZyBtYWluLXN0YWJ3ZWVr LTIwMjUtTWFyIGhhcyBiZWVuIHB1Ymxpc2hlZCBhdCBHbGViIFNtaXJub2ZmJ3MgZ2l0aHViIHJl cG8uPGJyIC8+VG8gY29ubmVjdCB0aGlzIHJlcG8gYXMgYW4gYWRkaXRpb25hbCByZW1vdGUgeW91 IG5lZWQgdG8gcnVuOjxiciAvPjxiciAvPsKgwqBnaXQgcmVtb3RlIGFkZCBnbGViaXVzIDxhIGhy ZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9nbGViaXVzL0ZyZWVCU0QiIHJlbD0ibm9vcGVuZXIgbm9y ZWZlcnJlciI+aHR0cHM6Ly9naXRodWIuY29tL2dsZWJpdXMvRnJlZUJTRDwvYT48YnIgLz48YnIg Lz5PbmNlIHJlbW90ZSBpcyBjb25maWd1cmVkLCB0byBjaGVja291dCB0aGUgdGFnIHJ1bjo8YnIg Lz48YnIgLz7CoMKgZ2l0IGZldGNoIGdsZWJpdXMgLS10YWdzPGJyIC8+wqDCoGdpdCBjaGVja291 dCBtYWluLXN0YWJ3ZWVrLTIwMjUtTWFyPGJyIC8+PGJyIC8+SWYgeW91IHdhbnQgdG8gdXNlIG9u bHkgdGhlIG9mZmljaWFsIEZyZWVCU0QgcmVwbywgdGhlbiB1cGRhdGUgdG88YnIgLz50aGUgcmV2 aXNpb246PGJyIC8+PGJyIC8+wqDCoGdpdCBwdWxsPGJyIC8+wqDCoGdpdCBjaGVja291dCA2N2Mx YzRkZmQxY2M8YnIgLz48YnIgLz5EZXZlbG9wZXJzIGFyZSBlbmNvdXJhZ2VkIHRvIGF2b2lkIHB1 c2hpbmcgbmV3IGZlYXR1cmVzIHRvIEZyZWVCU0QvbWFpbiBkdXJpbmc8YnIgLz50aGUgc3RhYmls aXphdGlvbiB3ZWVrLCBidXQgZm9jdXMgb24gYnVnZml4ZXMgaW5zdGVhZC4gVGhlIHN0YWJpbGl6 YXRpb24gd2VlazxiciAvPnJ1bnMgdXAgdG8gRnJpZGF5IDE4OjAwIFVUQywgYnV0IGlmIHRoZXJl IGlzIGNvbnNlbnN1cyB0aGF0IGFueSByZWdyZXNzaW9uczxiciAvPmRpc2NvdmVyZWQgYnkgcGFy dGljaXBhbnRzIGhhdmUgYmVlbiBmaXhlZCwgaXQgd2lsbCBlbmQgZWFybHkuPGJyIC8+PGJyIC8+ T25jZSB0aGF0IGhhcHBlbnMsIHRoZSBhZHZpc29yeSBmcmVlemUgb2YgRnJlZUJTRC9tYWluIGJy YW5jaCBpcyB0aGF3ZWQuPGJyIC8+wqA8L3A+LS08YnIgLz5HbGViIFNtaXJub2ZmPGJyIC8+wqA8 L2Jsb2NrcXVvdGU+PGRpdj5IaSBHbGViLDwvZGl2PjxkaXY+wqA8L2Rpdj48ZGl2PjxkaXY+PHNw YW4gc3R5bGU9IndoaXRlLXNwYWNlOnByZS13cmFwIj5KdXN0IGZvciBjb25maXJtYXRpb24uIEFm dGVyIHVwZGF0aW5nIG15IGxhcHRvcCB0byB2ZXJzaW9uIG4yNzYwNzMtNjdjMWM0ZGZkMWNjLCBu byBwcm9ibGVtcyB3ZXJlIGZvdW5kLiBBbGwgbG9va3MgZmluZS48L3NwYW4+PC9kaXY+PC9kaXY+ PGRpdj7CoDwvZGl2PjxkaXY+LS3CoDxiciAvPldpdGggQmVzdCBSZWdhcmRzLDwvZGl2PjxkaXY+ SWx5YSBBLiBBcmtoaXBvdjwvZGl2PjxkaXY+wqA8L2Rpdj4= From nobody Tue Mar 25 17:44:32 2025 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 4ZMckJ1t65z5rZ2S for ; Tue, 25 Mar 2025 17:44:40 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mx.catwhisker.org (mx.catwhisker.org [107.204.234.170]) (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 4ZMckH3DgYz3gBR; Tue, 25 Mar 2025 17:44:39 +0000 (UTC) (envelope-from david@catwhisker.org) Authentication-Results: mx1.freebsd.org; none Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.18.1/8.18.1) with ESMTP id 52PHiWKR037279; Tue, 25 Mar 2025 17:44:32 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.18.1/8.18.1/Submit) id 52PHiWre037278; Tue, 25 Mar 2025 10:44:32 -0700 (PDT) (envelope-from david) Date: Tue, 25 Mar 2025 10:44:32 -0700 From: David Wolfskill To: Olivier Certner Cc: freebsd-current@freebsd.org, src-committers@freebsd.org, Gleb Smirnoff Subject: Re: March 2025 stabilization week Message-ID: Mail-Followup-To: David Wolfskill , Olivier Certner , freebsd-current@freebsd.org, src-committers@freebsd.org, Gleb Smirnoff References: <6881633.Qb2xPn7ZBO@ravel> 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: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="bmUfZ9cMHb/F7Ud8" Content-Disposition: inline In-Reply-To: <6881633.Qb2xPn7ZBO@ravel> X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7018, ipnet:107.192.0.0/12, country:US] X-Rspamd-Queue-Id: 4ZMckH3DgYz3gBR X-Spamd-Bar: ---- --bmUfZ9cMHb/F7Ud8 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 25, 2025 at 10:39:56AM +0100, Olivier Certner wrote: > ... > I'd like to recommend cherry picking commit 718d1928f874 on top of the st= abweek tag for people using DRM kmod's amdgpu driver. It fixes longstandin= g bug PR 277476 (GUI freezes after some time, due to memory fragmentation) = for DRM kmod 5.15 or higher (5.10 is unaffected). >=20 > ... >=20 > If you test it, please report about your experience (even if it's just to= say "it works", or "I don't see any difference") and your GPU. >=20 > Thanks and regards. >=20 > --=20 > Olivier Certner TL;DR: No issues seen here. OK; well... not sure if this will help, but: * I track both stable/14 and head (and update installed ports under stable/14) on 3 machines daily: one headless build machine & 2 laptops. * The machines are set up so the same /usr/local is in place whether they are running stable/14 or head. * /etc/src.conf is set up so that ports-resident kmods are rebuilt (under the running OS) each time the kernel is rebuilt. * I had had some issues in head as of 15 March; "git bisect" had identified as main-n275968-19df0c5abcb9. * That identification was a "red herring" -- my laptop "head" kernels also have "options DEBUG_REDZONE" -- and it took "a while" for cleverer folks than I to see what the problem really was. Once markj provided a patch, I tried it, and that seemed to resolve the issue. * Sunday last, I updated head to main-n276051-29eb4de61a4c-dirty ("-dirty" because of the patch from markj). * Mark committed (& pushed) main-n276054-74361d693aec on Sunday; I managed to remember to "git restore sys/kern/kern_malloc.c". * Monday, I had updated head to main-n276073-67c1c4dfd1cc without issue. * Today (Tuesday, in my time zone as I write this), I updated head to main-n276079-718d1928f874 (which is the commit cite above); no issues. Caveat: I don't tend to run head much longer than it takes to build the next head & reboot into X11 (in the case of the laptops). I am using graphics/drm-61-kmod on the laptops. Peace, david --=20 David H. Wolfskill david@catwhisker.org "Any unauthorized release of classified information is a violation of the law and will be treated as such.=E2=80=9D Hmmm.... See https://www.catwhisker.org/~david/publickey.gpg for my public key. --bmUfZ9cMHb/F7Ud8 Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iNUEARYKAH0WIQSTLzOSbomIK53fjFliipiWhXYx5QUCZ+LrgF8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0OTMy RjMzOTI2RTg5ODgyQjlEREY4QzU5NjI4QTk4OTY4NTc2MzFFNQAKCRBiipiWhXYx 5TFgAP4sW6/sOGZbSx9gm3MkzBu4DCVGjCl1/ft888TLsKMajAEA18oQeHgYjQBK fD2R5m+3mFM44o9a/HgV3pGU8fJGCQY= =fAwZ -----END PGP SIGNATURE----- --bmUfZ9cMHb/F7Ud8-- From nobody Tue Mar 25 17:47:05 2025 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 4ZMcn90cncz5rZ33 for ; Tue, 25 Mar 2025 17:47:09 +0000 (UTC) (envelope-from glebius@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 "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZMcn864Y3z3hfR; Tue, 25 Mar 2025 17:47:08 +0000 (UTC) (envelope-from glebius@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1742924828; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=9MnjqZJCCjyuIkJVteWG/v56JGq1qw0booTQva9DxM8=; b=HmETlq6VkXxCKjHE4sG3pgF1/OsznNywxOrFMUbgv5bKkcYYV6SLf4Tds8Hfv1JEhoGO2E HAvTLdPMhre1cnUlw5mgQ3H/j+mUM0BQt49Uvzuom45UQ08lTHdSA6P93n8+mfTDDMWd0b 7oUHuQAgsrbj66+PJS8SFNR80VRsa4+fL2DBiUnnL1zaVX6o9MJ/Fb+QAHfpBYT8+5F44+ IRBgLGw9EwtBJcLeFzYBm7DO2zXnICPc+Hv0wdtHqFUTUYsit8vpgbSiaEzRAQFFrQRhpL eP3dCBXIxTWiYFGAWoHFYI8vDVYiOwsdA+p2Qhbh90htyJ3iLusUHSzB/wBCKg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1742924828; a=rsa-sha256; cv=none; b=bwQFztiSfZQt58gm8j5O2zAmR/usiZcp9Mat5QBoJGqfbgCC/DFTYAZBnJMht9pqHfQ4/B K1ZHHY3iQOwPWjy402p52rvAiFOe5u2j4xmPAvhvgFz8SzWQaCwOv9KK5n/XteONBR+mJh imDELyHhYzrHTR/G5AI1CioWGzyJ1uFHNsGrF+QE7dcZqxJR+immsoLIi43jGpyGSpY/p4 RRZeC5LK082FfXLFVS5i9sdNznM+JPtM1K5MxFqqdrlP4dBqUXyLyCiG9apfH+uJ5y+mfO /mtXSw83T29GlBQCTwfiR1WUlMTIprNwGfajsXPkQ2yJ32NM97WWXT53UVUxlA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1742924828; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=9MnjqZJCCjyuIkJVteWG/v56JGq1qw0booTQva9DxM8=; b=aHBn6qtsVOnszgzvcrYfUUYrIbsZn6zPWDPEf+erAL/VcerLlcmrwFtwZPAOkJKCJ2DZxW 51zCNxsx+9VjJQsn2wUi2CThj3Bq1ae2sJM8ehqeCBGLvGU7dDFtPpHwGF5tD1bwkcsv11 vxUTtDKVmWlcU09U9Rw8zQQwDqTlumjcq2eb2B9j1bXHAc/AZokTzW9LEygHgNhQVKpXhM NtPudzOxiIyaaiBhCzvMXW5cGlwHW3ww0h/nAk9Nk6GURbKq1Q8FNcza9SNKPGfje2cH3/ skDdi4ixNSsJ7YhJe/+3CK9kuDi+rZHlZAEyvmCSQHP70TId2vA4ZuS2Fh2Kkg== Received: from cell.glebi.us (glebi.us [162.251.186.162]) (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) (Authenticated sender: glebius) by smtp.freebsd.org (Postfix) with ESMTPSA id 4ZMcn82SjDz14kj; Tue, 25 Mar 2025 17:47:08 +0000 (UTC) (envelope-from glebius@freebsd.org) Date: Tue, 25 Mar 2025 10:47:05 -0700 From: Gleb Smirnoff To: freebsd-current@freebsd.org, src-committers@freebsd.org Subject: Re: March 2025 stabilization week 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: On Mon, Mar 24, 2025 at 01:00:11AM -0700, Gleb Smirnoff wrote: T> This is an automated email to inform you that the March 2025 stabilization week T> started with FreeBSD/main at main-n276073-67c1c4dfd1cc, which was tagged as T> main-stabweek-2025-Mar. At Netflix testing we didn't find any stability or performance regressions with the stabweek tag. Several people (including myself) updated their laptops and workstations and confirmed everything went smooth. This time I got more feedback than usual, several people emailed me privately or on a media outside of the freebsd- current@ mailing list. Very glad and grateful seeing more participation! Thanks everyone! The stabweek is over, advisory freeze is thawed! Note 1: those running on AMD GPUs are adviced to use 718d1928f874 hash for update, or cherry-pick just this hash on top of the stabweek hash. It fixes a long standing bug (not a recent regression!) and unfortunately was pushed after the stabweek was tagged. Note 2: There is a new LOR between tcpinpcb and socket buffer lock if you use kTLS and kernel is compiled with INVARIANTS. We assume this LOR safe, and not having any chance of a deadlock. Nevertheless, I'll try to figure out how to get rid of it. -- Gleb Smirnoff From nobody Tue Mar 25 20:53:01 2025 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 4ZMhvc6r01z5rmxj; Tue, 25 Mar 2025 20:53:00 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZMhvb3Fgfz3JBh; Tue, 25 Mar 2025 20:52:59 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=G6rRXcMI; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rick.macklem@gmail.com designates 2a00:1450:4864:20::52b as permitted sender) smtp.mailfrom=rick.macklem@gmail.com Received: by mail-ed1-x52b.google.com with SMTP id 4fb4d7f45d1cf-5e5e22e6ed2so9415640a12.3; Tue, 25 Mar 2025 13:52:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1742935978; x=1743540778; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=ykuMpv0z8ghbNWBUh9kmoCeAB4Tr1onR2bPNfc9gSZI=; b=G6rRXcMIFX9nkYbV3HVMJK9v9+OO29QTHL5thq2oYvXYq581fGPl+aCPBXlrDZPwCw mZXt4Z9ZRdjMVMAotOdXtQII9p3SKMCpRyOyMQRHIhPg0FcvrO/6gv2pOMev7r4ZQR8M iWk09iw7IPfCwvUIJs4rtteY7WnvHjzzlAxiN9UX02ia0keeHRgVqBVqSnXl1pwI5P1u G07onwuhEMUzJxZBtwDd7Dnl//IU+gCYgMsFsKXvmgWDEpUwDTtizXGugxTyyMn7Jm/D vbHtRqW52oulj/RjOnL9Kxs3m9POonwGwFkdpSxZdz/bUdZvfMOOr+yT1nWfW0Recmf+ 54Dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742935978; x=1743540778; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ykuMpv0z8ghbNWBUh9kmoCeAB4Tr1onR2bPNfc9gSZI=; b=U+aURFZ1+FkD5jLeTPIdIuhmiMl1wuWCL/qHxvNTiTHn8zL/xTfYkgRfG6RdexUwnj NTk1lFUQUiqF73TKZfcdWo3ynFUbBW5INMB5rAkI9hmntHFKARLzGmR/6xVWdUT0SxDs 8/g9HGfQOdoufQCjdpt4iX2wWtekGtSyB+QI/WFSdvwlw37XdB49NkD31dg7GLfLut4M y29CeXrDffHHc2MSqXRi1ILaEBwinWI2nqsTOogyMVW6CZm2WsjXm8wy1J4vnFYbE3Vi t6dedz6LeCWUKZQfnv5cC1UX+7eBYCKBMjm3BTySYvwKRJLaSnl3KGm9Ls13E83PWF/c xCGg== X-Forwarded-Encrypted: i=1; AJvYcCUJGoTCtpyDNJenvqv17LKSwanyuQj3xQOGekMLIgVP+Dx6sDTf5PtEG8B5dtyDoM4JE/WP@freebsd.org, AJvYcCWdgb3g6/4zEAblm/lWjb7r+aRtw8ge7AlmT+aLqrjabxTtQE7FL0s9MsJCrB1Pw4djaIBzjx0YNv7VcfA=@freebsd.org, AJvYcCWlpJ3YGNM+vFihS25MovP4Dizmu6wP46R/CIKPGS4s0PQdf0yP/bF2C51ilOKuVzRtcXSLk938We7Hjy1j/3W6@freebsd.org X-Gm-Message-State: AOJu0Yx9dOo5e2wTufbk2PDhhkSOJ6PIYGt4t53dwBOA/BJFxFPUUgVh 8Mx4T/8qmi2grp39btZwg0z2B1BnLqL6PH/U0U08d/hKcsiYQv1SUOaoUOaKn1p92nauoTalQFY P9GY/OdH0vczRHg98cInZ/t7rrIiD X-Gm-Gg: ASbGncuIGwlM3vEWATp9zDY+/8Cj8OOinqEaZ3KFMO7yZ54hSYdi+COE7i61kObb3jr ReNY3IsNEV451VgEGmJrXchInFzbYTeDF5gMs/osHFj4mpBdO/jlZexTrxIsYocMrhNN3MsH407 B1UA2UmRxBzSrDsaHr73DFbXokJvugrYkQaI59+NJoEkSvZjMBIDIUV7BBKlSXgff0/bIA X-Google-Smtp-Source: AGHT+IG0KMT3cvsEMN5ttJ4PMYu/95/6dRYibSbpOascD3IuUrkpzd66fELP+TpV8uXYj+Is2PXIA6XoyIgvp1kcoew= X-Received: by 2002:a05:6402:4404:b0:5e7:110a:c55 with SMTP id 4fb4d7f45d1cf-5ebcd45f766mr18762127a12.18.1742935977643; Tue, 25 Mar 2025 13:52:57 -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: In-Reply-To: From: Rick Macklem Date: Tue, 25 Mar 2025 13:53:01 -0700 X-Gm-Features: AQ5f1JqHIrkIitgpppVtmqtt1nht5HHIs20Yd5Ft2WjRk2ONjUQHpuSGdJRbsMI Message-ID: Subject: Re: RFC: Solaris style extended attributes for FreeBSD To: Lionel Cons Cc: Andrew Walker , Konstantin Belousov , freebsd-arch@freebsd.org, FreeBSD CURRENT , Cedric Blancher Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Result: default: False [-1.17 / 15.00]; SUSPICIOUS_RECIPS(1.50)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.98)[-0.984]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_SPAM_LONG(0.31)[0.310]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; TAGGED_FROM(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::52b:from]; FREEMAIL_TO(0.00)[gmail.com]; ARC_NA(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_FIVE(0.00)[6]; MID_RHS_MATCH_FROMTLD(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org,freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_CC(0.00)[ixsystems.com,freebsd.org,gmail.com]; TAGGED_RCPT(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; DKIM_TRACE(0.00)[gmail.com:+]; MISSING_XM_UA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com] X-Rspamd-Queue-Id: 4ZMhvb3Fgfz3JBh X-Spamd-Bar: - On Tue, Mar 25, 2025 at 12:06=E2=80=AFPM Lionel Cons wrote: > > On Sat, 22 Mar 2025 at 21:34, Rick Macklem wrote= : > > > > On Sun, Mar 9, 2025 at 5:38=E2=80=AFAM Andrew Walker wrote: > > > > > > > Since ZFS is already wired for them, adding the basics is pretty > > > > straightforward. I am not suggesting that they should replace the > > > > current FreeBSD extended attributes > > > > > > The ZFS story is more complicated. When ZFS is configured with > > > `xattr=3Dsa`, xattrs are preferentially written into system attribute= s > > > (SA). This was introduced IIRC primarily for performance reasons > > > This allows tiny xattrs (~100 bytes) to be stored with the dnode and > > > up to 64 KiB of xattrs to be stored in the dnode spill block. If > > > additional space is needed then they are written using the older-styl= e > > > file-backed approach. > > > > > > What this means is that if someone is using this relatively common > > > configuration (the default in TrueNAS and in many Linux distros), the= n > > > the result would be that only some xattrs written via extattr would b= e > > > visible by directly opening the ZFS attr dir. It would also introduce > > > a mechanism whereby an xattr with the same name is written to two > > > different ZFS locations, which would potentially cause you to see > > > different xattr data depending on whether you read it from extattr or > > > via the attr dir. I don't know off-hand whether this could lead to > > > corruption / unexpected behavior in ZFS but if you haven't looked int= o > > > it yet you may want to make sure you're properly handling the case > > > where someone has already written SA-backed xattrs. > > I am in the process of defining a new setting for the xattr property > > I've called "named" which would need to be set for the Solaris style > > extended attributes to work. > > > > I am making progress on the patch and am currently working through > > permissions (or authorization if you prefer). > > > > Here is what OpenZFS appears to do currently. > > I am wondering if these sound reasonable for these attributes? > > > > - When an attr directory is created for a file object, the ownership > > (uid and gid) is set to the same value as the file object. > > The mode is set to 041777 (a directory with sticky bit set and > > permissions for everyone. (It ignores the "mode" argument to > > the open.) > > --> As such, anyone who has access to the file object can access > > the extended attribute directory. > > Yes, that is the expected behaviour > > > > > - When an attribute is created in the attribute directory, the uid is > > set to that of the creating process (cr_uid), the gid is set to that > > of the directory (which is also the gid of the file object). > > The mode is set to that of a regular file with low order mode bits > > as specified by the "mode" argument to the openat() that created > > it. > > The mode can be changed with fchmod(2). > > --> As such, access to each attribute file is controlled by the > > attribute file's creator. > > > > Any comments on the above? > > Yes, that would be the expected behaviour. > > > > > A couple of other questions... > > - Should subdirectories of the attribute directory be supported? > > I currently do not allow this, but it appears to be supportable > > by both OpenZFS and NFSv4. > > No, please no subdirs for now. As far as I can see all consumes of > such an API (Windows, MacOS etc) use flat layouts for the attribute > and alternate data streams virtual dirs > > > > > - Does restricting this support to ZFS file systems with the > > xattr property set to "named" sound reasonable? > > What does that mean? > Also, it should be "on" by default, both in FreeBSD ZFS, UFS and NFS >=3D= v4.1 Hmm. I think (and the discussion with Andrew seemed to confirm it) that they do not mix well with FreeBSD/Linux style extended attributes. (For example, the code that checked access for the parent directory is disabled for FreeBSD style attributes and this is intentional, according to the comment.) Also, I doubt anyone will ever do support for UFS? (I am certainly not volunteering.) The above means that a sysadmin will need to choose between which style of extended attributes they want on a "per file system basis" and that Free= BSD style will be the default, since to change that would be a POLA violation, = imho. (If others feel that having the two styles co-exist on the same file system is needed, there might be a way to do it, but doing so properly won't be easy. Another example is naming. If both co-exist on the same file system, you can end up with two different attributes with the same name. I did this during testing, so I know it can happen.) > > > > > Thanks for any comments, rick > > ps: I have not, as yet, heard any comments w.r.t. whether or > > not this should go into FreeBSD15. (No rush on this one, > > but comments would be appreciated. > > I'd prefer the integration as soon as possible. A couple of problems here. 1 - You and Cedric are the only ones that have spoken up with support for t= his. (Having said that, no one has spoken up against it.) 2 - Someone needs to do the "userspace" lifting at some point. I haven't yet asked, so I do not know if you feel commands like "chmod= (1)" need to be "named attribute aware"? (The fchmod(2) syscall works, but does the command line need to know how to do it? If yes, this is work. Probably more than I've spent getting the syscalls to work.) 3 - A lot of the changes need to go into OpenZFS and I have no idea what their position will be? (Most of the changes are in the os/freebsd/zfs source subtree, which may make it easier?) rick > > Lionel From nobody Tue Mar 25 21:14:04 2025 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 4ZMjND1f1Xz5rnvH; Tue, 25 Mar 2025 21:14:20 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZMjNC2cvwz3Wgj; Tue, 25 Mar 2025 21:14:19 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b="SH/WegaN"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rick.macklem@gmail.com designates 2a00:1450:4864:20::536 as permitted sender) smtp.mailfrom=rick.macklem@gmail.com Received: by mail-ed1-x536.google.com with SMTP id 4fb4d7f45d1cf-5e6167d0536so1026236a12.1; Tue, 25 Mar 2025 14:14:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1742937257; x=1743542057; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=hQgAZTr7fZSlCmKqP3zbQ7WaYXWiewKe5baw/AD0ALQ=; b=SH/WegaNsyocdi4yO3OyPKsXupXMxak4OqDoOsvDb/3iUFmcby3KVhqpALNQWiNDxi Fn9ovHhDL9bHC2HPCI/GM1VrbHx6P3TIMmaPtR10W90PYAtL8iyC8+71VgtfSaZu1jT/ 6BMS3PEpH4S1Bq7q6M+MabKpN2q/UyzEfae+0Mhy3WyShvMjWG/crzUwXprXTzoJgCk5 MC86BQ8mkDmKNpfl6Eh/1o8SXe9A7vBEYQKotYsgN4/VcGPhtA9acDboLmZocd9JUvgB Ni24LqQpwopJ0JU4gouQV+MYKy6lgMnTaA66AKzwBnKAk4rfJ3ripj48Qw4GRwhKni+Y 7m8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742937257; x=1743542057; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=hQgAZTr7fZSlCmKqP3zbQ7WaYXWiewKe5baw/AD0ALQ=; b=UqMUs4N7T9+8fWQwh66K9h7IqgKBnbODfuVMueEFmdNfVnCTieXdVM40dvuB2gN9CI QttUWdiOdHVyPjLdb4Kl/ZhnGwLUkG9TscQOfNSuP5tSAP4/miFRdwOZPfmTXfou/sun HrbZgeduNSh1wiwbUqvI7QZPhwJ+uZtupq9wYg1vUxEs28+APnqJq1H8VNOYoHpY9ZUy uA6quGl3WKbzl5tn51jSUb2ngESSuqdu3g4LSyKEUUgNhe+ue5f+Q0UZtjwsB/V3CypT 9h7xJEh1HYjZgT8YsNO1qzBW4IP8pEG/GMogxj1dp0UIPH5Tdhn0ErDY77KDqnMjYiQH nFqw== X-Forwarded-Encrypted: i=1; AJvYcCUTlTSGBhjPwa9LtIpkNBRWIdDSGS37jYPsZ3C9nG7VxzdyPSRyLlKmVokQntaRKxt8mPnw@freebsd.org, AJvYcCVvuIcqaL6t17y3y5BGR7cAKZqwAAgUzUGBTJprScXtIJGqoaebFOl16o+OV69jRDwP9CntpxD+mryKKLg=@freebsd.org, AJvYcCVw98iOKTQL8WjKraVz2L5ujKIxeygq+TO7MfdkRXCZP1zWj6GtWZj/plFTTqELGf+biDJAyDBUPkHhvRn8Yap1@freebsd.org X-Gm-Message-State: AOJu0YyY3/SDIIWAvJ179x8BvXTXFJ37BxWzVovOe2K8l1t1Ka1zP8bO boEao7FMWpQcl/F2leuEFfbAgJGDPdRmU9Vn2xsHnNf/OtkdexjqhWrYFhFHt/HgK27iPPSi/kH qgG8gP5l6hkbxR045qOLOWvhXsA== X-Gm-Gg: ASbGncv6ZPdKQEp6MssLzog2FryjHYe0i+kAOEfHz1owPNgVkkLjQygPmaA001OagiH ivUQtXYTiM/hGURqk+BzqL8h9o9/pNP/011PK1wEjkp7RvGyOTwfEa+xjFU73cTuq9tAiuRyRkM MYqhorq7MLXIUFlvAra+j0uX184AQ0jGxsfxNoe2JfHVFqlDZGpriPcQ+LnQ== X-Google-Smtp-Source: AGHT+IHdDSTc2g57nc5KywPtXkf0FmjraRcVR3bLAIHnzL7WzpjDkY+//SR1QBVBFqceSyknWoXqduq+rp1r/drTMqw= X-Received: by 2002:a05:6402:1d4e:b0:5e7:2871:c137 with SMTP id 4fb4d7f45d1cf-5ebcd436714mr14771443a12.14.1742937256527; Tue, 25 Mar 2025 14:14:16 -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: In-Reply-To: From: Rick Macklem Date: Tue, 25 Mar 2025 14:14:04 -0700 X-Gm-Features: AQ5f1JpuwqDgzaZWnHju2jxmwAkcWWMAMSIybZDJB-620XOfNm93ZDrF5_fgu5Y Message-ID: Subject: Re: RFC: Solaris style extended attributes for FreeBSD To: Lionel Cons Cc: Andrew Walker , Konstantin Belousov , freebsd-arch@freebsd.org, FreeBSD CURRENT , Cedric Blancher Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Result: default: False [-2.50 / 15.00]; SUSPICIOUS_RECIPS(1.50)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; MIME_GOOD(-0.10)[text/plain]; TAGGED_FROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::536:from]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; FREEMAIL_TO(0.00)[gmail.com]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+]; TO_DN_SOME(0.00)[]; FREEMAIL_CC(0.00)[ixsystems.com,freebsd.org,gmail.com]; MISSING_XM_UA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; TAGGED_RCPT(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org,freebsd-current@freebsd.org]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCPT_COUNT_FIVE(0.00)[6] X-Rspamd-Queue-Id: 4ZMjNC2cvwz3Wgj X-Spamd-Bar: -- On Tue, Mar 25, 2025 at 1:53=E2=80=AFPM Rick Macklem wrote: > > On Tue, Mar 25, 2025 at 12:06=E2=80=AFPM Lionel Cons wrote: > > > > On Sat, 22 Mar 2025 at 21:34, Rick Macklem wro= te: > > > > > > On Sun, Mar 9, 2025 at 5:38=E2=80=AFAM Andrew Walker wrote: > > > > > > > > > Since ZFS is already wired for them, adding the basics is pretty > > > > > straightforward. I am not suggesting that they should replace the > > > > > current FreeBSD extended attributes > > > > > > > > The ZFS story is more complicated. When ZFS is configured with > > > > `xattr=3Dsa`, xattrs are preferentially written into system attribu= tes > > > > (SA). This was introduced IIRC primarily for performance reasons > > > > This allows tiny xattrs (~100 bytes) to be stored with the dnode an= d > > > > up to 64 KiB of xattrs to be stored in the dnode spill block. If > > > > additional space is needed then they are written using the older-st= yle > > > > file-backed approach. > > > > > > > > What this means is that if someone is using this relatively common > > > > configuration (the default in TrueNAS and in many Linux distros), t= hen > > > > the result would be that only some xattrs written via extattr would= be > > > > visible by directly opening the ZFS attr dir. It would also introdu= ce > > > > a mechanism whereby an xattr with the same name is written to two > > > > different ZFS locations, which would potentially cause you to see > > > > different xattr data depending on whether you read it from extattr = or > > > > via the attr dir. I don't know off-hand whether this could lead to > > > > corruption / unexpected behavior in ZFS but if you haven't looked i= nto > > > > it yet you may want to make sure you're properly handling the case > > > > where someone has already written SA-backed xattrs. > > > I am in the process of defining a new setting for the xattr property > > > I've called "named" which would need to be set for the Solaris style > > > extended attributes to work. > > > > > > I am making progress on the patch and am currently working through > > > permissions (or authorization if you prefer). > > > > > > Here is what OpenZFS appears to do currently. > > > I am wondering if these sound reasonable for these attributes? > > > > > > - When an attr directory is created for a file object, the ownership > > > (uid and gid) is set to the same value as the file object. > > > The mode is set to 041777 (a directory with sticky bit set and > > > permissions for everyone. (It ignores the "mode" argument to > > > the open.) > > > --> As such, anyone who has access to the file object can access > > > the extended attribute directory. > > > > Yes, that is the expected behaviour > > > > > > > > - When an attribute is created in the attribute directory, the uid is > > > set to that of the creating process (cr_uid), the gid is set to th= at > > > of the directory (which is also the gid of the file object). > > > The mode is set to that of a regular file with low order mode bits > > > as specified by the "mode" argument to the openat() that created > > > it. > > > The mode can be changed with fchmod(2). > > > --> As such, access to each attribute file is controlled by the > > > attribute file's creator. > > > > > > Any comments on the above? > > > > Yes, that would be the expected behaviour. > > > > > > > > A couple of other questions... > > > - Should subdirectories of the attribute directory be supported? > > > I currently do not allow this, but it appears to be supportable > > > by both OpenZFS and NFSv4. > > > > No, please no subdirs for now. As far as I can see all consumes of > > such an API (Windows, MacOS etc) use flat layouts for the attribute > > and alternate data streams virtual dirs > > > > > > > > - Does restricting this support to ZFS file systems with the > > > xattr property set to "named" sound reasonable? > > > > What does that mean? > > Also, it should be "on" by default, both in FreeBSD ZFS, UFS and NFS >= =3D v4.1 > Hmm. I think (and the discussion with Andrew seemed to confirm it) > that they do not > mix well with FreeBSD/Linux style extended attributes. (For example, > the code that > checked access for the parent directory is disabled for FreeBSD style > attributes and > this is intentional, according to the comment.) > > Also, I doubt anyone will ever do support for UFS? (I am certainly not > volunteering.) > > The above means that a sysadmin will need to choose between which style > of extended attributes they want on a "per file system basis" and that Fr= eeBSD > style will be the default, since to change that would be a POLA violation= , imho. > (If others feel that having the two styles co-exist on the same file > system is needed, > there might be a way to do it, but doing so properly won't be easy. > Another example > is naming. If both co-exist on the same file system, you can end up > with two different > attributes with the same name. I did this during testing, so I know it > can happen.) > > > > > > > > > Thanks for any comments, rick > > > ps: I have not, as yet, heard any comments w.r.t. whether or > > > not this should go into FreeBSD15. (No rush on this one, > > > but comments would be appreciated. > > > > I'd prefer the integration as soon as possible. > A couple of problems here. > 1 - You and Cedric are the only ones that have spoken up with support for= this. > (Having said that, no one has spoken up against it.) > 2 - Someone needs to do the "userspace" lifting at some point. > I haven't yet asked, so I do not know if you feel commands like "chm= od(1)" > need to be "named attribute aware"? (The fchmod(2) syscall works, bu= t > does the command line need to know how to do it? If yes, this is wor= k. > Probably more than I've spent getting the syscalls to work.) > 3 - A lot of the changes need to go into OpenZFS and I have no idea what > their position will be? (Most of the changes are in the os/freebsd/z= fs > source subtree, which may make it easier?) Oh, and another one... Testing. I have yet to hear from anyone trying to test the code. I obviousl= y do some testing, but my resources are limited. For example, the pynfs test suite does have some xattr testing in it. However, I haven't used the pynfs test suite in a long time and am not a Python guy. It would be nice if someone else fired it up and did this testing. (If problems are found, I could probably track them down and fix them.) rick ps: In case you do not know, I am one guy who does this NFS stuff as a spare time hobby. I am not paid any $$$ by anyone to do it. > > rick > > > > > Lionel From nobody Tue Mar 25 21:26:12 2025 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 4ZMjf138Vkz5rpXn for ; Tue, 25 Mar 2025 21:26:17 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZMjdz5y5Rz3hRP for ; Tue, 25 Mar 2025 21:26:15 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=hardenedbsd.org header.s=google header.b=UjNkWr2R; dmarc=none; spf=pass (mx1.freebsd.org: domain of shawn.webb@hardenedbsd.org designates 2607:f8b0:4864:20::d2e as permitted sender) smtp.mailfrom=shawn.webb@hardenedbsd.org Received: by mail-io1-xd2e.google.com with SMTP id ca18e2360f4ac-85b58d26336so512748239f.2 for ; Tue, 25 Mar 2025 14:26:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd.org; s=google; t=1742937974; x=1743542774; darn=freebsd.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=0hIP9aCLWX64lvAdYx7a4CEPEHgF3jnnVH7WIMnr3Q4=; b=UjNkWr2RUbl9tXjSxuB+2zrHCjaD8GTzQ/2HI18Th3I2OCQqcD/uyAOo9+ruG8LGgE CoQO1lkhUtaognPx+WuQrusgzLqo8ChzZJlQQw0upR0S87eUlzdDlC60+Mw02hwYcujl y+0yKyrSwjwXqXda0AEZSEFNTqVFk21p83osSLTpGBauzGHZEHBmBXDWhlc+J+nz3aL2 gVP2WDTWD0ZMuQVmukyJgYAdDBNU32/BQvTfvWTFfifN5N7l6YOFNEnvhoCV4R9A9UjC R/g2RRdvRPkJPfdGe1kCfIXyhmdH4wdQmv8klLVbgUvXpQvnDBcPhD4UvAjVIvDWukLk /ngw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742937974; x=1743542774; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=0hIP9aCLWX64lvAdYx7a4CEPEHgF3jnnVH7WIMnr3Q4=; b=EIRh434Z2PzhpjRLkbq98kULcBcaMlhdsUrDeY5jQw+NQwKXtCXTCHQzccyCt1e18b /7JxrcKp8lo1jITYdC7AxNKDxsFyisDOJxgl4ktfhSsQC/yNviY8MS0Q+lpCrBM4R3Q2 mcG6cXDLEUQx+gLOx0LJ/NS6fG2n+RHwMWKShbza81vfkReKz6e/NI3DqP5Vyppl7zJE Z7kvC3qSGWus3dpPDsvXWItCPAEFSdP+gYyPV1KG3YgrZdPfG4cl/4kciU8Omya3vrOY +HkPcLflncIo8odXsJ+fucFcNkJ6syKwu2BkSlMgpBeUO8tNvRaKw8Eidt3fvrYiJG0z 86bA== X-Forwarded-Encrypted: i=1; AJvYcCVCihM/bav+AQl9IA0JpEC6mqIvbGVB5WpGGbJRvtSOFi/96Tk2zJdlC6AnhXph40XkkItkoi1GAL1Sm90TReM=@freebsd.org X-Gm-Message-State: AOJu0Ywvd5oKCGBRsG2C9fEtIVAmtT+Y0qDWJDl4s1dC1ffXuFcjOFdf lTXkzAfG8qybA1OsTub2NL3QuDrHxAiLv+0eOCJLR/1aY3UY6apjqrJHSHgT5v8= X-Gm-Gg: ASbGncu4gMVX+WrdENiA6rIjlr5R6M9uDwyXxMQIC3dCMf+oVuUTeWpjh4PbNNiojrD UETmTOZS0g80+mMBRenarGPObHDEtBfDdwAm319AXalEQPD8gPWBsc6KVPuLZ9WqR/Sz8sS8wKy sjVRdrtC3WCKY5Ef5ed3j1WlkMEdhDtIQxEaG1PBXrARYjOSRQ+MWSLFHQUkzEiO5pV+UNiWU+X yMZJG1yA+oldy/RwGzAmM0zWO8C0IWFzPuLhak24Q2XVegt3dk0iYld9IDIbsyqhiQEVDVjlB4H zBPR1VYTP6DrEH5Gbw3q0jj7FDo= X-Google-Smtp-Source: AGHT+IFxdFR8DQnffv5z7d7BdZWPHRNJtPI/Gn4ZfpaSzDw+WR3d0dDrC9kcMAqyVbHogejxojwgbg== X-Received: by 2002:a05:6602:3890:b0:85b:3885:1592 with SMTP id ca18e2360f4ac-85e2cc60643mr1882832039f.10.1742937974272; Tue, 25 Mar 2025 14:26:14 -0700 (PDT) Received: from mutt-hbsd ([2001:470:4001:1::95]) by smtp.gmail.com with ESMTPSA id 8926c6da1cb9f-4f2cbecd047sm2495168173.143.2025.03.25.14.26.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 25 Mar 2025 14:26:13 -0700 (PDT) Date: Tue, 25 Mar 2025 21:26:12 +0000 From: Shawn Webb To: Rick Macklem Cc: Lionel Cons , Andrew Walker , Konstantin Belousov , freebsd-arch@freebsd.org, FreeBSD CURRENT , Cedric Blancher Subject: Re: RFC: Solaris style extended attributes for FreeBSD Message-ID: X-Operating-System: FreeBSD mutt-hbsd 14.2-STABLE-HBSD FreeBSD 14.2-STABLE-HBSD HARDENEDBSD-14-STABLE amd64 X-PGP-Key: https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/blob/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc 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: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="tlncmezvkdrnvgah" Content-Disposition: inline In-Reply-To: X-Spamd-Result: default: False [-5.09 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.988]; MID_RHS_NOT_FQDN(0.50)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; R_DKIM_ALLOW(-0.20)[hardenedbsd.org:s=google]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; DMARC_NA(0.00)[hardenedbsd.org]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_CC(0.00)[gmail.com,ixsystems.com,freebsd.org]; DKIM_TRACE(0.00)[hardenedbsd.org:+]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; MISSING_XM_UA(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_SEVEN(0.00)[7]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; TO_DN_SOME(0.00)[]; TAGGED_RCPT(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::d2e:from] X-Rspamd-Queue-Id: 4ZMjdz5y5Rz3hRP X-Spamd-Bar: ----- --tlncmezvkdrnvgah Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: RFC: Solaris style extended attributes for FreeBSD MIME-Version: 1.0 On Tue, Mar 25, 2025 at 01:53:01PM -0700, Rick Macklem wrote: > On Tue, Mar 25, 2025 at 12:06=E2=80=AFPM Lionel Cons wrote: > > > > On Sat, 22 Mar 2025 at 21:34, Rick Macklem wro= te: > > > > > > On Sun, Mar 9, 2025 at 5:38=E2=80=AFAM Andrew Walker wrote: > > > > > > > > > Since ZFS is already wired for them, adding the basics is pretty > > > > > straightforward. I am not suggesting that they should replace the > > > > > current FreeBSD extended attributes > > > > > > > > The ZFS story is more complicated. When ZFS is configured with > > > > `xattr=3Dsa`, xattrs are preferentially written into system attribu= tes > > > > (SA). This was introduced IIRC primarily for performance reasons > > > > This allows tiny xattrs (~100 bytes) to be stored with the dnode and > > > > up to 64 KiB of xattrs to be stored in the dnode spill block. If > > > > additional space is needed then they are written using the older-st= yle > > > > file-backed approach. > > > > > > > > What this means is that if someone is using this relatively common > > > > configuration (the default in TrueNAS and in many Linux distros), t= hen > > > > the result would be that only some xattrs written via extattr would= be > > > > visible by directly opening the ZFS attr dir. It would also introdu= ce > > > > a mechanism whereby an xattr with the same name is written to two > > > > different ZFS locations, which would potentially cause you to see > > > > different xattr data depending on whether you read it from extattr = or > > > > via the attr dir. I don't know off-hand whether this could lead to > > > > corruption / unexpected behavior in ZFS but if you haven't looked i= nto > > > > it yet you may want to make sure you're properly handling the case > > > > where someone has already written SA-backed xattrs. > > > I am in the process of defining a new setting for the xattr property > > > I've called "named" which would need to be set for the Solaris style > > > extended attributes to work. > > > > > > I am making progress on the patch and am currently working through > > > permissions (or authorization if you prefer). > > > > > > Here is what OpenZFS appears to do currently. > > > I am wondering if these sound reasonable for these attributes? > > > > > > - When an attr directory is created for a file object, the ownership > > > (uid and gid) is set to the same value as the file object. > > > The mode is set to 041777 (a directory with sticky bit set and > > > permissions for everyone. (It ignores the "mode" argument to > > > the open.) > > > --> As such, anyone who has access to the file object can access > > > the extended attribute directory. > > > > Yes, that is the expected behaviour > > > > > > > > - When an attribute is created in the attribute directory, the uid is > > > set to that of the creating process (cr_uid), the gid is set to th= at > > > of the directory (which is also the gid of the file object). > > > The mode is set to that of a regular file with low order mode bits > > > as specified by the "mode" argument to the openat() that created > > > it. > > > The mode can be changed with fchmod(2). > > > --> As such, access to each attribute file is controlled by the > > > attribute file's creator. > > > > > > Any comments on the above? > > > > Yes, that would be the expected behaviour. > > > > > > > > A couple of other questions... > > > - Should subdirectories of the attribute directory be supported? > > > I currently do not allow this, but it appears to be supportable > > > by both OpenZFS and NFSv4. > > > > No, please no subdirs for now. As far as I can see all consumes of > > such an API (Windows, MacOS etc) use flat layouts for the attribute > > and alternate data streams virtual dirs > > > > > > > > - Does restricting this support to ZFS file systems with the > > > xattr property set to "named" sound reasonable? > > > > What does that mean? > > Also, it should be "on" by default, both in FreeBSD ZFS, UFS and NFS >= =3D v4.1 > Hmm. I think (and the discussion with Andrew seemed to confirm it) > that they do not > mix well with FreeBSD/Linux style extended attributes. (For example, > the code that > checked access for the parent directory is disabled for FreeBSD style > attributes and > this is intentional, according to the comment.) >=20 > Also, I doubt anyone will ever do support for UFS? (I am certainly not > volunteering.) >=20 > The above means that a sysadmin will need to choose between which style > of extended attributes they want on a "per file system basis" and that Fr= eeBSD > style will be the default, since to change that would be a POLA violation= , imho. > (If others feel that having the two styles co-exist on the same file > system is needed, > there might be a way to do it, but doing so properly won't be easy. > Another example > is naming. If both co-exist on the same file system, you can end up > with two different > attributes with the same name. I did this during testing, so I know it > can happen.) >=20 > > > > > > > > Thanks for any comments, rick > > > ps: I have not, as yet, heard any comments w.r.t. whether or > > > not this should go into FreeBSD15. (No rush on this one, > > > but comments would be appreciated. > > > > I'd prefer the integration as soon as possible. > A couple of problems here. > 1 - You and Cedric are the only ones that have spoken up with support for= this. > (Having said that, no one has spoken up against it.) > 2 - Someone needs to do the "userspace" lifting at some point. > I haven't yet asked, so I do not know if you feel commands like "chm= od(1)" > need to be "named attribute aware"? (The fchmod(2) syscall works, but > does the command line need to know how to do it? If yes, this is wor= k. > Probably more than I've spent getting the syscalls to work.) > 3 - A lot of the changes need to go into OpenZFS and I have no idea what > their position will be? (Most of the changes are in the os/freebsd/z= fs > source subtree, which may make it easier?) Hey Rick, I don't really have anything of importance to relay. While on the subject of filesystem extended attribute support with ZFS, though, I noticed that the support is broken for processes that have entered Capabilities Mode (called cap_enter(2)). I filed a bug report almost a year ago with both FreeBSD and OpenZFS. It might be worth a look: 1. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D277908 2. https://github.com/openzfs/zfs/issues/16058 Thanks, --=20 Shawn Webb Cofounder / Security Engineer HardenedBSD Tor-ified Signal: +1 303-901-1600 / shawn_webb_opsec.50 https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A= 4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc --tlncmezvkdrnvgah Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEA6TL67gupaZ9nzhT/y5nonf44foFAmfjH2EACgkQ/y5nonf4 4frEqQ/+I/Y+0EOsXLvenmL/6ISISNBGQKyaweFlJ6XJgRfogDkq3mAzNGJ4CF65 Ply8COM8/pRlCvr0OMfUZQy8bye22ttv+UXslesDbI7y1044m7qQS/y21Q9vgtsg QRTn3cjjdpiTCSYJfH65tBV6rMSqoaSV2DAGeA4Hq0QK22cj8mpRuv9uiCSiQ3Nz IwlJuFDJh9wAuucfsOcjJ6o7KDSszBTOd5P6YKJBbxKi4+dlMFPfEes5pOPiKjpL nshSQSG6UQ9e4WfMIQZdzTzWcXslFJNDVUNMugz+4w+7EMGv4VfsiGjEjPEoB0OU drapQQ4u06YdXHAbCdxsoTfa1A0NNlne5BZcUiV6II7tdS2VDNIXw7A+pxU7rVc7 6vsK2SVrRffuy5iUcmpQzNLM2oeYbsEX0r9z6vpM1dPw1Hh1gDJ+cC7yYNOOu/7M eXh6plWsZu39yjyFOH8EaiETy20v5Bmql4JxTPDQPcW8Yfw6mGD+p09HM3tMwuU/ xY7mihZnGpkFrTlxO7Ko4jO7nxosHZlVikgmYfT+NzEnLSTiIvbiHPObcq43leZm VgEGULCdxboCAz+KFZXbiDkfdJdtlphIvATsDICVkApTb/wnl5TQcZWbPCABpmKx BJtaa3F/JsnL/1tY3ykPGJ4SspKS9WFsPadxZ+NOWzcVZIBSJZM= =g0// -----END PGP SIGNATURE----- --tlncmezvkdrnvgah-- From nobody Wed Mar 26 10:15:51 2025 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 4ZN2kB3Tc5z5rjM4 for ; Wed, 26 Mar 2025 10:16:02 +0000 (UTC) (envelope-from olce@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 "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZN2kB1jwTz40Wc; Wed, 26 Mar 2025 10:16:02 +0000 (UTC) (envelope-from olce@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1742984162; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=RKN8EQZQ5ybXva/NgohKPhcJwze7VCqSB5jebdJVyNU=; b=xdalHWT5+4kHoIKYsE1qmY3r1oJAWaxxJX6xXJFjsfLm/k0Z/dIoIinvvoEB2uGVZJ/UG+ pWymtJIrT1YVrw0w1jKfdvwqCzOZlCecbEYwKfeI3gmoTSeB2tgtFrj/pevoUAj9WzvbQF HqgNS7fkTPJOwxx9YGOKJjyHa/E9X8PcvIT46S2i5Eygg/s3H39feC1XO9pdZejksJPVaS Cx2zmv+YbCyTzIIBm2KrI+7nMYEtPF2fPlkM5GSZfYnV/fzIxf3idyrd2+BSrPAeRFQqHN aB74CWttYVkZ9YZ68YqVgUiD1rQc6cQnI3JR1x78IZ9O/6KiAS09EOz8Rn1/wQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1742984162; a=rsa-sha256; cv=none; b=WXADoIzLh5vTxsbSwc2n+yf09STIheoMeLmvwb/pRXbCAzaRR8sqJhPpc93DuEop1Po4SN qNrdDxlT6JrYvPm/CrquFhhMNuf7l5/XmH6IKtVAhxfoiaaIpFhidtjfOke/SXCwF4JIG6 vH4lyOKnget/lWODfEuqEQ1n6pbEvKHaQLeQHz6RRIvZuIRnByjz2YbZMq/E6VyNEyM31V XVrfjlJo8yfsPeIf4Yo1sohTcEib0odH64/0eOhT9xSJvV2iObdmseCMsV53T9U5or1TSL dKDqYTLRyGkMHUPGsGMlYjeak6wf4splWQh0znHvYMyskyTEBUp1EVqVMPoPSA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1742984162; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=RKN8EQZQ5ybXva/NgohKPhcJwze7VCqSB5jebdJVyNU=; b=Rzmoec17d9rJjN/Gg0GYdkHuFDEAEB7cdPzdMymFs0w2X5ICfhKksKdhzZuwKumy8N9YNl 3hWUHHar7avg1LUQUCGUya/QDoK+5ef7cljwewk5o2IEE4Qgxqo1Fm/mzWVfpunoT4a2Z0 RQ8UNfYTuJF7jlTSSHIHCrbg/QaTrRXLyarkQzdaaYiUgm0nL2dloWCAg03Cn7XfnewX83 6tYd2i6xYmAIytwTMQV1c0pzjSVN+nXldOFWi/b49oQotuvoLdc6pAQMqdQWgtdh7Bl8rP C5yZ2C4J46cnO1dGu3Fvl8QNca6gUXZCzTcKMwT1xKm6Tl5Xsz6j9WIg+HlD6g== Received: from ravel.localnet (aclermont-ferrand-653-1-222-123.w90-14.abo.wanadoo.fr [90.14.66.123]) (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) (Authenticated sender: olce/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4ZN2k94Fckz1Q24; Wed, 26 Mar 2025 10:16:01 +0000 (UTC) (envelope-from olce@freebsd.org) From: Olivier Certner To: David Wolfskill , freebsd-current@freebsd.org, src-committers@freebsd.org, Gleb Smirnoff Subject: Re: March 2025 stabilization week Date: Wed, 26 Mar 2025 11:15:51 +0100 Message-ID: <3068086.hHqAuc6tWs@ravel> In-Reply-To: References: <6881633.Qb2xPn7ZBO@ravel> 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: multipart/signed; boundary="nextPart2427734.THHZn3L5Ee"; micalg="pgp-sha384"; protocol="application/pgp-signature" --nextPart2427734.THHZn3L5Ee Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="UTF-8"; protected-headers="v1" From: Olivier Certner Subject: Re: March 2025 stabilization week Date: Wed, 26 Mar 2025 11:15:51 +0100 Message-ID: <3068086.hHqAuc6tWs@ravel> In-Reply-To: MIME-Version: 1.0 Hi David, Thanks very much for reporting. > * Today (Tuesday, in my time zone as I write this), I updated head to > main-n276079-718d1928f874 (which is the commit cite above); no issues. Did you rebuild drm-61-kmod after upgrading to 718d1928f874? Due to how the Linux-compatibility for alloc_pages*() works, the changes in 718d1928f874 will have no effect on your setup otherwise (__GFP_RETRY has been compiled to 0 if using the previous header when compiling drm-61-kmod). Thanks and regards. -- Olivier Certner --nextPart2427734.THHZn3L5Ee Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCQAdFiEEmNCxHjkosai0LYIujKEwQJceJicFAmfj09cACgkQjKEwQJce Jicg9w/+JYNjE+FzzyY5fccTI5IFvoyfUlO/8RFX1FL5HtuEOZBfjZyT/RDRel1M RCZamsIVrACxoMts9rQfpIn+3RoLUraKzkh8q2mbKICuKk7YUWeKyOyXyAiHbri3 I7Bb3mmOOJ74d1SMD3++h8HkDqmsQCeIE/o8WNAxPXwjabvxTBrtZDaGdMgF7UAw un1rolVznw0TV2og28ppnoI9QLetpbSQQB/K9lt0TLJTdGL1JWcOoOhDrABgCFjT iZKPmcxMPEZoCFC1U6HvwSX7g5WzOjH//3QbJijEzPOWTR5q6Ztr5BPCuJQKTPxV soz1XBbdE3ptJ/YcEOB/uds74cTohaFPzvNlBnjhj96yTFvvBGTS0qwfmEQ2KMUr EGKBcwCSc1bSndC7s78Rclb8cIholb8Wsl9Z7F2AUkZLtKGSAJs1Uxqwy9ngXwor YuhJMIvLpZd/1LPrxbf6+L+vFsaxW6tuoptkQ0G6u0l0iT8PJUHYFom4g6eqMPuA vsDuB4mOh1OkELpssm76kAeQcs/4qSnjGK55u+LvCAb69Sn6UQvhzT5QSyUSW+K8 QPbtTsyrV1hWi2pvEDTBPG006Gs5JaGBdIiiZ5Z7cJe5HlK4uTqWS+AlyRlef39H p6083c/vVwZl66tanDI1yoZRPWrE6OtQVFj8/PbVoncWtxCF440= =IJwa -----END PGP SIGNATURE----- --nextPart2427734.THHZn3L5Ee-- From nobody Wed Mar 26 10:39:25 2025 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 4ZN3FD4JPWz5rlDr for ; Wed, 26 Mar 2025 10:39:28 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mx.catwhisker.org (mx.catwhisker.org [107.204.234.170]) (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 4ZN3FD0Kq4z3CNM; Wed, 26 Mar 2025 10:39:27 +0000 (UTC) (envelope-from david@catwhisker.org) Authentication-Results: mx1.freebsd.org; none Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.18.1/8.18.1) with ESMTP id 52QAdPt4045661; Wed, 26 Mar 2025 10:39:25 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.18.1/8.18.1/Submit) id 52QAdPgm045660; Wed, 26 Mar 2025 03:39:25 -0700 (PDT) (envelope-from david) Date: Wed, 26 Mar 2025 03:39:25 -0700 From: David Wolfskill To: Olivier Certner Cc: freebsd-current@freebsd.org, src-committers@freebsd.org, Gleb Smirnoff Subject: Re: March 2025 stabilization week Message-ID: Mail-Followup-To: David Wolfskill , Olivier Certner , freebsd-current@freebsd.org, src-committers@freebsd.org, Gleb Smirnoff References: <6881633.Qb2xPn7ZBO@ravel> <3068086.hHqAuc6tWs@ravel> 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: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="cbymbhvDBeRzkVqK" Content-Disposition: inline In-Reply-To: <3068086.hHqAuc6tWs@ravel> X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7018, ipnet:107.192.0.0/12, country:US] X-Rspamd-Queue-Id: 4ZN3FD0Kq4z3CNM X-Spamd-Bar: ---- --cbymbhvDBeRzkVqK Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 26, 2025 at 11:15:51AM +0100, Olivier Certner wrote: > Hi David, >=20 > Thanks very much for reporting. :-) > > * Today (Tuesday, in my time zone as I write this), I updated head to > > main-n276079-718d1928f874 (which is the commit cite above); no issues. >=20 > Did you rebuild drm-61-kmod after upgrading to 718d1928f874? Due to how t= he Linux-compatibility for alloc_pages*() works, the changes in 718d1928f87= 4 will have no effect on your setup otherwise (__GFP_RETRY has been compile= d to 0 if using the previous header when compiling drm-61-kmod). >=20 > Thanks and regards. Yes: g1-118(14.2-S)[1] grep '^PORT' /etc/src.conf PORTS_MODULES+=3Dgraphics/drm-61-kmod g1-118(14.2-S)[2] gen_fbsd_git_tag stable/14-n270849-b0d6aa07c193 g1-118(14.2-S)[3] grep '^PORT' /S4/etc/src.conf PORTS_MODULES+=3Dgraphics/drm-61-kmod g1-118(14.2-S)[4] gen_fbsd_git_tag -r /S4/usr/src main-n276079-718d1928f874 Peace, david --=20 David H. Wolfskill david@catwhisker.org "Any unauthorized release of classified information is a violation of the law and will be treated as such.=E2=80=9D Hmmm.... See https://www.catwhisker.org/~david/publickey.gpg for my public key. --cbymbhvDBeRzkVqK Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iNUEARYKAH0WIQSTLzOSbomIK53fjFliipiWhXYx5QUCZ+PZXV8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0OTMy RjMzOTI2RTg5ODgyQjlEREY4QzU5NjI4QTk4OTY4NTc2MzFFNQAKCRBiipiWhXYx 5e3EAQCRCKqu1mnNdckJS7rBp1rMFgfv+KR53sY/2pYtGf12ZQD/e99U+KgsNKqt EQ9wBI/ejR2kB6njiPoVX4c8igk4Rg8= =72lZ -----END PGP SIGNATURE----- --cbymbhvDBeRzkVqK-- From nobody Wed Mar 26 10:55:45 2025 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 4ZN3c84nvXz5rlrl for ; Wed, 26 Mar 2025 10:55:52 +0000 (UTC) (envelope-from olce@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 "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZN3c83RzRz3Mf2; Wed, 26 Mar 2025 10:55:52 +0000 (UTC) (envelope-from olce@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1742986552; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=gcpfI43zJXOFjdHJCXzVqpqo/bMrHSLETY9G8A+cGjY=; b=tLUYZljyZfXUn/PrBW/4AMEXBBs0wG2hTFE084s8j2n3am+LGIRFW4d6JpL13YQrZpBYee CJ7NNTx+3X9gaMcvTgk4g4knCrWHzlGTP547AwgZ/rIpVtdDjeJCOfs5MCWFyrc7keXgMV R7PVa87nBzQWX8PGKv4uhaNQaBP1tuH4JBHVibMKA+naR78sPmyjYNMOOP7DENXMXmxEMv awOwPBZtKZN76O+JZL+jmoVEk3ssblffjPZLHWtwGbBejYRgaIDaqh/6Yrj9tmvpBlLSdx dj4vgqGHKSl/kT4QSEh+VkjU1sDm/xknwEvTH8GF6qt8xmJmsC9S43puyjNyOA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1742986552; a=rsa-sha256; cv=none; b=qYzVYM+iTszwHA9OJUxKwWQOhkrJWncS9edBSreIe3sOMRPE7Fm1Px9nQuJ3s5MDbdSZGY wArmTmm2HfNTxtWwFmXQLRyOZPHUqg25wBheLVZwn9NuT52CSUFWsVqGi/F8ThPjISQpba AmHWnvLEIFUMi2fHQXuvUVAPcXqqK9/rpBbipIU1LMzAjqIvwHul3vE6OV9nFetbqJa+ON nuKjX208MgHOV45oc8HFrjmf/fY32xbIhepfq9Q1CqRHGsvb6Uq2bkyN/f12RDCr3F6gcL IlOeIoCZ91yjuPiQxTclH4Q7QsA3kpyaqCj3buBeWhsLBIX3a4znFHXX/hLdpQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1742986552; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=gcpfI43zJXOFjdHJCXzVqpqo/bMrHSLETY9G8A+cGjY=; b=GhybB7xdPyZKjknI2FfiqbZEoM3A5OI2D47zuLw4TPGUNrlu3UMeeO/zYrzq3y3xoMc4cS lu+aeW81dBrRBNgj5mL1kz9mwGYw2N4vkordazOuSLt7nm49EUldQafyog4Ao1EtJrNrEu MLzrAczRkSqUHvtnv94DR2yBxh4lRQugMl8vNuBauMsTt3EDR+V85vxq7Ia1+7koa6Qxtr FR4MHd0a5slHcw1xn/Yy6JPVh4Wjkj+lhst9ZXqfF9Esqt/pKerTjMvyEnlL0GQlTKgnAN AACqWhT1Nc8FOjBT75ZvnWZ7TdpwN8mfZm4SnrKbpxMJljCBO8LlMswsEk799Q== Received: from ravel.localnet (aclermont-ferrand-653-1-222-123.w90-14.abo.wanadoo.fr [90.14.66.123]) (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) (Authenticated sender: olce/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4ZN3c75w2gz1RCW; Wed, 26 Mar 2025 10:55:51 +0000 (UTC) (envelope-from olce@freebsd.org) From: Olivier Certner To: David Wolfskill , freebsd-current@freebsd.org, src-committers@freebsd.org, Gleb Smirnoff Subject: Re: March 2025 stabilization week Date: Wed, 26 Mar 2025 11:55:45 +0100 Message-ID: <2139326.x0N0T6uNKo@ravel> In-Reply-To: References: <3068086.hHqAuc6tWs@ravel> 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: multipart/signed; boundary="nextPart2321196.sMrx5ctUpN"; micalg="pgp-sha384"; protocol="application/pgp-signature" --nextPart2321196.sMrx5ctUpN Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="UTF-8"; protected-headers="v1" From: Olivier Certner Subject: Re: March 2025 stabilization week Date: Wed, 26 Mar 2025 11:55:45 +0100 Message-ID: <2139326.x0N0T6uNKo@ravel> In-Reply-To: MIME-Version: 1.0 > (snip) Yes (snip) Great. Thanks! -- Olivier Certner --nextPart2321196.sMrx5ctUpN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCQAdFiEEmNCxHjkosai0LYIujKEwQJceJicFAmfj3TEACgkQjKEwQJce JifpKBAAnmH4sJjUlaQ8YmwqqpcPYl0BujfomsbUrDXOcJj2RJ6pGzHWo3R8WQ3C kjbVBY2Sr8dx9yWlQsdyJ148WszGeT2TbDqKcqB/h8P1rzF1ATUJXJM4KpEMGkZS BHAKSFktdlylP107s+rfyHnC6Da2VOmX7N7augGBKghyEp2gDCM53an0RxNtoOpq MZUosrtVepPvmXXEVr37KAw+Fr2orPPa5r8+qHd+p618SSP+ca0c5d8JqM8B0NXP UCUuKyf72VMATZ1CbIevsvdlLCgJDdHGPNTvQ61WEqde/0US51llynX5tv3OyOhP Wd3qYsrPy9/r3G1pXsf/SmDcU1NaYMexlRfVKuN103pFlDGjn2kZJp/P4GtrWg6o eCetHKTODWRWqOEPoWFfjSjjaVB2Ey6tO4d941WPdJInQ2PEhsg1aQ2Td7tqT9Rh 7iaox/EbhpggFr5IDjUez2+j85pfCzzVBMTj3DdIDWbZ4vVtEevTGqCFR2WcRTxi IHvpNTJiFxIGsOmbsk5YdYurOBSKzRGh+9Z9oDsTDWkQyQi0J7TJUOOhPVIKCyId 4iLmbhvyKVH5OP5UurEiFmgDBSdF2lIS/0XfvCSLc7DtrBUC+N9WvX5Ei+gLhPRj Mbvs/YAZ1Hu/8lvHZVIfpfELBdEme+457NM7CslpYbEM1ddTZJM= =C2fG -----END PGP SIGNATURE----- --nextPart2321196.sMrx5ctUpN-- From nobody Wed Mar 26 12:39:14 2025 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 4ZN5vk4q8Lz5rtXG for ; Wed, 26 Mar 2025 12:39:30 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZN5vf6pdjz4Gl7; Wed, 26 Mar 2025 12:39:26 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=dec.sakura.ne.jp header.s=s2405 header.b=tBEecJ3N; dmarc=pass (policy=none) header.from=dec.sakura.ne.jp; spf=pass (mx1.freebsd.org: domain of junchoon@dec.sakura.ne.jp designates 153.125.133.21 as permitted sender) smtp.mailfrom=junchoon@dec.sakura.ne.jp Received: from kalamity.joker.local (124-18-43-114.area1c.commufa.jp [124.18.43.114]) (authenticated bits=0) by www121.sakura.ne.jp (8.17.1/8.17.1/[SAKURA-WEB]/20201212) with ESMTPA id 52QCdEpw084987; Wed, 26 Mar 2025 21:39:16 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dec.sakura.ne.jp; s=s2405; t=1742992757; bh=95fwzAHfEuk/GS820VseueumVxUUBsutuBsel+5jxSc=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=tBEecJ3NpgkZxvg8e5EPGHKHnysMrIn3Hb3p9ofCLGAGpChJfrSoUsWsl5TKuv1+9 YsSCcfbLxTDS9e7LM+QxCLEK1m8pBaUWDBRJSXMOgR7Y9acV90SB4L11j1me0GBxwL MQw1r7e6vKJLVDCgaV42WC4KBSzZZyUQNEs/y35Y= Date: Wed, 26 Mar 2025 21:39:14 +0900 From: Tomoaki AOKI To: Olivier Certner Cc: freebsd-current@freebsd.org, Gleb Smirnoff Subject: Re: March 2025 stabilization week Message-Id: <20250326213914.6d9b9e33e3f19822c5f98116@dec.sakura.ne.jp> In-Reply-To: <6881633.Qb2xPn7ZBO@ravel> References: <6881633.Qb2xPn7ZBO@ravel> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.2) 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-Transfer-Encoding: 7bit X-Spamd-Result: default: False [-0.53 / 15.00]; SUSPICIOUS_URL_IN_SUSPICIOUS_MESSAGE(1.00)[]; NEURAL_HAM_LONG(-1.00)[-0.999]; NEURAL_HAM_MEDIUM(-0.97)[-0.971]; NEURAL_HAM_SHORT(-0.86)[-0.861]; MV_CASE(0.50)[]; URIBL_RED(0.50)[dec.sakura.ne.jp:dkim,dec.sakura.ne.jp:mid,dec.sakura.ne.jp:email]; ONCE_RECEIVED(0.20)[]; HAS_ANON_DOMAIN(0.10)[]; MIME_GOOD(-0.10)[text/plain]; BAD_REP_POLICIES(0.10)[]; DKIM_TRACE(0.00)[dec.sakura.ne.jp:+]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; R_DKIM_ALLOW(0.00)[dec.sakura.ne.jp:s=s2405]; RCVD_TLS_LAST(0.00)[]; HAS_ORG_HEADER(0.00)[]; ARC_NA(0.00)[]; DMARC_POLICY_ALLOW(0.00)[dec.sakura.ne.jp,none]; RCVD_COUNT_ONE(0.00)[1]; TO_DN_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(0.00)[+ip4:153.125.133.16/28]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP]; MIME_TRACE(0.00)[0:+] X-Rspamd-Queue-Id: 4ZN5vf6pdjz4Gl7 X-Spamd-Bar: / Hi. Removed ML I cannot post to from CC list (I'm not a committer). On Tue, 25 Mar 2025 10:39:56 +0100 Olivier Certner wrote: > Hi, > > I'd like to recommend cherry picking commit 718d1928f874 on top of the stabweek tag for people using DRM kmod's amdgpu driver. It fixes longstanding bug PR 277476 (GUI freezes after some time, due to memory fragmentation) for DRM kmod 5.15 or higher (5.10 is unaffected). > > The patch has been reviewed and battle-tested by multiple people on different hardware for weeks to months, so we expect no regressions of any sort. That said, as the current plan is to MFC this change to stable/14 before releng/14.3, more testing, with possibly different hardware, is always welcome and would be great. > > If you test it, please report about your experience (even if it's just to say "it works", or "I don't see any difference") and your GPU. > > Thanks and regards. > > -- > Olivier Certner Currently just a FYI: I myself don't using amdgpu driver, but tried to cherry-pick (not `git cherry-pick, but tried applying diff as a patch) it on stable/14, amd64 at commit b429d50df97bc6f85373d4bd4ffca7e7078b3fe8, which failed on sys/compat/linuxkpi/common/src/linux_page.c. *Just to be sure it doesn't harm graphics/nvidia-drm-*-kmod once it is MFC'ed, as I cannot take enough time to test on main, and current state of my main branch is older than it. There seems to be a prerequisite, at least commit 2619c5ccfe1f7889f0241916bd17d06340142b05. Not sure more to be required, nor some part of the commit does harm or not, as I've stopped investigating this for now. [1] https://cgit.freebsd.org/src/commit/?id=2619c5ccfe1f7889f0241916bd17d06340142b05 Regards. -- Tomoaki AOKI From nobody Wed Mar 26 14:01:13 2025 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 4ZN7k53J5Nz5s06P for ; Wed, 26 Mar 2025 14:01:17 +0000 (UTC) (envelope-from garga@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 "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZN7k46ZBrz3hKm for ; Wed, 26 Mar 2025 14:01:16 +0000 (UTC) (envelope-from garga@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1742997676; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding:autocrypt:autocrypt; bh=Tk60i5KmGU7KZghziMxdydsycZoFsbasJWSQ4E0ljjs=; b=Iv971q/kxOsNbuVsxt9ltkLGqQMBrKu0O+wOYqsfqWwDObFhWzKjXWCkIo2er8EEqo70Cg PdFmlc32p2bObItZ9Yd/BKVTsScxTLlQtoxnOLeDSl+vJH46ZwGUqXB85we7H5+4sNrclN cb5vg5KJ4mJYhcxsK7jO9UbDVIvH2FXzeOHFDYVrOQEpHzkp0nE/IBP3qpSjJE9l+I2Kbq PUEKE0Sx+P3TSupH33PzAe6q+PPRIiT212npEElD2uFhMscgp6fmAGxK2wADXJ+H2f7u0G GCPO1d0MSmLf9/WPUHzg0lDMgTtmTrbdQ1jD/uEB29UI6aI7j9dMzp/sonSvzQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1742997676; a=rsa-sha256; cv=none; b=MRZp7k0EnCKvNfJd9optvbJtIGTGUZwGNUEL1Io5OSK4J4J7ZNclLqxvYHnsvfwsCZwllp pmH5yTwtD8H/IiDuplDrBwwpcN0gzeAHwzv7sZxyRJ52lgvxPAgmn/B6Xf2EYbNspzj/ou v4aDXAN5XDcau6eB+nbAbFhfJs9l4c4F8owmwdOzuCMpPjQl/lt5+tPGiVEbE1MgNRRkzA NY2F13pl4CdAli0nLYdGG3mKu04OjprJ8vBti8krCpNLnejRzKWd1GaQz/kUjgjihnOQN4 WDwP9X9F5N+3Q595UbrLqPM9BcfdN+2Co+mWR5ZSYorSzGk3EBIAXwXibFDCng== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1742997676; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding:autocrypt:autocrypt; bh=Tk60i5KmGU7KZghziMxdydsycZoFsbasJWSQ4E0ljjs=; b=s2sb9bTgDywo0mdB9n8ekOAjS2J+JX5/V4JxZO96Dc3hMxk1crMzlIJYP386ZoQE1wClsO pECCiyzpvPjGZ59Li2I0CSUpJRXUUaNZ5vRlPFWEVSF1TGQQ3bMU1rdXVEk+wURW/ss/Dp lyiQjFmiGCFU9dxTuBFflfmRDIe61vbmjQaSUYx4Yfg4N/Udum4AkH82SvAOh7IivWPV3v eWtfVfhGeN+1yk0aELS0f/iOkzHiMcM9hsiUGGbBfL+go01nfd7tlVacKrPdcy9C9AQTVj +4iz9BAOW4SzsunhLe59BUEGgG/kB7DspMkxZ9+nv+0Dxs98/Svqzg9ex32Umw== Received: from [IPV6:2804:f1c:802:dd01:dc2:16a0:ba12:b959] (unknown [IPv6:2804:f1c:802:dd01:dc2:16a0:ba12:b959]) (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 did not present a certificate) (Authenticated sender: garga) by smtp.freebsd.org (Postfix) with ESMTPSA id 4ZN7k448hqz22j for ; Wed, 26 Mar 2025 14:01:16 +0000 (UTC) (envelope-from garga@FreeBSD.org) Message-ID: <30322e00-271d-41f7-aa76-48e5074018b2@FreeBSD.org> Date: Wed, 26 Mar 2025 11:01:13 -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 Thunderbird X-Mozilla-News-Host: news://news.gmane.io:119 Content-Language: en-US To: Current FreeBSD From: Renato Botelho Subject: suspend/resume broken on Thinkpad x230 Autocrypt: addr=garga@FreeBSD.org; keydata= xsBNBGStavwBCACjNlp/9+Y+VFe9ieR2h/WWbdvjz4Mb2z/f22bGoaskzCfvVNbo/v3i34I9 H6OdgZkGqheQEAD2jNfRbmPr4z40xDMUpYGLds+1Mvg7G3Hms3j5Ef8KaLSWUNWIfwKdfSVR Qs35ccSJxAdRW5YdI6J3xZgika+3Bc4eJ05YE/nWW+PNTYevt5rqD50N3zybVYIcLoqVPpBi AZE/sf5SLiLACIJb1t/s4x+pi8vgWevxVVT9u8V1f8zYErmHSLSqjxii0B3eRZphX9NCJOv9 +tfFZhnENInhn9gT7H4e2YumUltEy3jacONHJF3CC1pvvWEa6lEyypclMOkHQwNON7DLABEB AAHNLFJlbmF0byBCb3RlbGhvIChGcmVlQlNEKSA8Z2FyZ2FARnJlZUJTRC5vcmc+wsCXBBMB CgBBAhsDBQkFo5qABQsJCAcDBRUKCQgLBRYDAgEAAh4FAheAFiEERL7Dxegbnh7xTiQ5Ob6P xxJcZXoFAmSta78CGQEACgkQOb6PxxJcZXrYlggAgaZmr6c1yIWzN8VksHrHpwt/uxONEP+h ljy3yfrMsgfS5wx5Uzgfih1xYZUFC6jiI63CetqBqJpp3g1klRS1UWYKx2NeXphDMYZEdPm/ a6sXh4bKZbk6IE8Yn0/YiRT57d9DtbvswC7Gn7Igj/MSbhl49TvTGyvuB6juaffVoYZViomx 5zMoee8Ml2o2qj3MrCJ+/K8GU54RlpOGqGRsqdwVdr9XEWub6fF2YFwR46cjmbiU3P5urFHH nkJlBGPIwKxHimTW0lZsdx9aCKRDd/D80/WOEzXmk3k8B9lv/GsvOluHmveLhJG1R1tIJ31I f2q8dfTvqsQXnu8CcWRcgc7ATQRkrWr8AQgA1DufoxScA+CWQbUR6zExIu8wXQKrhuRt4DG2 BgynT7EMUvEBadcbQRZXsBpemNfncc9Axyut/+rWiyKJf9BLQuo/9QYmSRvW1U6+0LJUYmdg kMyBeYaPk+vnssv/u9jLuvV7FVgyE0yk1iaWIKOVDD+XrQCOvGw9uSceBrQyCyo3A/eRM/+p vnDCaywR63PKE+3axk6lfNdGK3TnaWmS30/ZDCZlNsXuqprqR4JdT5wXids5o36dsuJ5EZ20 s5hNMD34s4Yr1Y1R9elH6qBsFCpozs0+jwrArxq+UJJCR6hH5W8ZEwJtRC8tzR8mRE1WywzX BXYj0YhfGztQIxZckQARAQABwsB8BBgBCgAmFiEERL7Dxegbnh7xTiQ5Ob6PxxJcZXoFAmSt avwCGwwFCQWjmoAACgkQOb6PxxJcZXr1vgf/SKXhoZcUU5I7TqcbHg0lJz9tICTupCGHWr/s SQgjh9oEM5j1wqW7FlCGP90Tl9K0g3ow9YdbhU7VK470o6pymX9V9eLHzGgkZO/KMEtGBeK1 u+5ePjCJ/MK5B21KODLSU7WrIL1VN5ceXfQPLYt02LMLtPri+oduHD6RNBeA7US1DUzleq5F 9NHGbvV2U7BdDUezpiO8NaFjFZVB11I5d99FxUM5XGVstI3VhsRKZxjY0KnqJzaQgTFsPGmv AUfZVIN1pXgXiedhPXpr8+Y64jP+pHVwpVmh1zYWL6+q3kqFOUVP6c5iiMeoEXZvgJz7x/AC ek3X5gvu8Hpcv+MZIg== Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit I'm using pkgbase to upgrade system running on this laptop and unfortunately, since it took some time for me to notice the issue, I don't have a good BE available to check a good commit hash before problem was introduced. It's running Wayland and Sway and when I resume graphical interface is so slow that I am not able even to type my password and leave screen lock. I could SSH into it and noticed load avg was high, I also listen fan is in high speed but system is so slow that I couldn't collect much information. My system is now running main-n276047-0849f1634a70. Another user reported same problem on his thinkpad x270 laptop. He is running Xorg. His broken system is running main-n276084-2f1f523a45fb and latest good version was main-n276005-91d8ee3579ef. -- Renato Botelho From nobody Wed Mar 26 14:43:36 2025 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 4ZN8gC2N4Qz5s2WT; Wed, 26 Mar 2025 14:43:51 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZN8gB2s2Hz432r; Wed, 26 Mar 2025 14:43:50 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=APbSPM5+; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rick.macklem@gmail.com designates 2a00:1450:4864:20::530 as permitted sender) smtp.mailfrom=rick.macklem@gmail.com Received: by mail-ed1-x530.google.com with SMTP id 4fb4d7f45d1cf-5dccaaca646so1996656a12.0; Wed, 26 Mar 2025 07:43:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1743000228; x=1743605028; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=9mY2qXC+hCoh9OzLaaoY+Ee4m4qMyehkuxjC4JFsLVY=; b=APbSPM5+EBg+FZP+I4CS25d02jxr8RdpL+WeLEii420dchsYCKCTIA6WEH8BphB4pU bmOJ68WMu+EeWL62NR5xMJr9dAkxqSLgeR5n1Rh2sl5QbwuNrwbKVFSFjOWsxM4TTcoY 0d4OQOMjfqtp4hBGDaZNqNatpY7I9meb3qnhtd8se/26C1m9P+nxsyVNgPk0QpFQjvF5 6x8eGlzmLaNDKfo7kGZOo5Khx+X1PXo+INmAv+ln4S00QbWMUaowqrLxhTy2cZPXMpCg m6Palktak6rOAL/m873plqYRhlili/Vwp4fsZqehrhj4XRr2KLu+Uzq4x0zB/MLk9FKL ylAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743000228; x=1743605028; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=9mY2qXC+hCoh9OzLaaoY+Ee4m4qMyehkuxjC4JFsLVY=; b=kYlHfzZOh6LBz0gfhSQrTEWbsk/rRG+OzNiTu6+pEdaABWoR8H6xcN/Wnjw9ZqEglA 6lFBPjIqKc73P1pmSP3zgpz84NoI8D4DEPfJxcVcYwTu88iYPacEo3ZTifPNeIo3IQKI MmLw0CaK0y1xzozVfFTpsgePcZRClPAWeeiF780iWkBpa4UJune+JC/0R1d1/J/q7y95 SHk1IAeRb1irLd/E7iNQM+FeeD4MS1HSxzQmwKpl1l5irnOP5jtqeqtbArjAMjMs4inH VRNjkntv69opV7pq8o+YDvPsMQFvCyCpFTRpaGz1qpPpOFeJCd5T64Svu//e+lPw3Vad /MEg== X-Forwarded-Encrypted: i=1; AJvYcCUOg6aJUPxPwFVX0nKb+/k4pH/sEMvnp4BARyY0LvMts/SOTuU3WsP5tC5ts9a84GEVDtHK@freebsd.org, AJvYcCUklnD+HOSrt3mpSPdOzY6B0yibAT4329h0B2traZ0X2C2AZfN1Gb2VCeW6FJNnMPJs8T0E0Yqu4C/IZ9AaRUrS@freebsd.org, AJvYcCWTYfGnxwmesROVcYFv8A+AwBWtrm8g9ceyl07ADlqt0HD8lcC3e5aUUvPrdopDH4DZOnNyHIryhWUnUyw=@freebsd.org X-Gm-Message-State: AOJu0YyMbgRcVhFPTUISlAC9Pb2nDs8DXLNJBYBH2r3v73CZ+vCVWUoh L7U/haNqDoxNzOHggyNODp6Gtyi+/h+E9OcZ5HxxHg8alEBLAms/34RfOv1phanY6N5RkAdJ0T3 jtkDbJc82zHmNBVQSJ7hTpl4IiLbl X-Gm-Gg: ASbGnctNhYjKJ7iMfgnoWZD5d4CQqoWkDQXr/xOUMopgRlNiD5515fbu05ZRvSHm1mX 4jn6oRCSgJrxwn8imObKblbnl9NR/+hV2LI8Q8bVa9jrBW0dquGIvuAN0M2ebe+Y9O3py4mrWbq ARN8nIgUf3kWkWWj0+tBfMlTXwWMKxxG/ftuMQo9KwUbD6wvjyDxUbUZBgZw== X-Google-Smtp-Source: AGHT+IEmvs6YhUZ4Fu5xFl6ijj0xUJHn+8tpU8l49/g65qraETvyPzNn/QmkwXuDddEqo5h/7f3hRg+H1DUrDbgAuHQ= X-Received: by 2002:a50:9b0b:0:b0:5ed:53f7:a46c with SMTP id 4fb4d7f45d1cf-5ed53f7a592mr2455374a12.12.1743000227693; Wed, 26 Mar 2025 07:43:47 -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: In-Reply-To: From: Rick Macklem Date: Wed, 26 Mar 2025 07:43:36 -0700 X-Gm-Features: AQ5f1JpQ7_HjzLlsteq5st_W6_J_E-hYiMoHCnoP40UTFjaSVemJNhf8UwJBxFw Message-ID: Subject: Re: RFC: Solaris style extended attributes for FreeBSD To: Lionel Cons Cc: Andrew Walker , Konstantin Belousov , freebsd-arch@freebsd.org, FreeBSD CURRENT , Cedric Blancher Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Result: default: False [-2.48 / 15.00]; SUSPICIOUS_RECIPS(1.50)[]; NEURAL_HAM_SHORT(-1.00)[-0.999]; NEURAL_HAM_LONG(-0.99)[-0.995]; NEURAL_HAM_MEDIUM(-0.99)[-0.986]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; TO_DN_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::530:from]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; FREEMAIL_FROM(0.00)[gmail.com]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_FIVE(0.00)[6]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_CC(0.00)[ixsystems.com,freebsd.org,gmail.com]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org,freebsd-current@freebsd.org]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TAGGED_RCPT(0.00)[]; MISSING_XM_UA(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; FREEMAIL_ENVFROM(0.00)[gmail.com] X-Rspamd-Queue-Id: 4ZN8gB2s2Hz432r X-Spamd-Bar: -- On Wed, Mar 26, 2025 at 2:39=E2=80=AFAM Lionel Cons wrote: > > On Tue, 25 Mar 2025 at 22:14, Rick Macklem wrote= : > > > > On Tue, Mar 25, 2025 at 1:53=E2=80=AFPM Rick Macklem wrote: > > > > > > On Tue, Mar 25, 2025 at 12:06=E2=80=AFPM Lionel Cons wrote: > > > > > > > > On Sat, 22 Mar 2025 at 21:34, Rick Macklem = wrote: > > > > > > > > > > On Sun, Mar 9, 2025 at 5:38=E2=80=AFAM Andrew Walker wrote: > > > > > > > > > > > > > Since ZFS is already wired for them, adding the basics is pre= tty > > > > > > > straightforward. I am not suggesting that they should replace= the > > > > > > > current FreeBSD extended attributes > > > > > > > > > > > > The ZFS story is more complicated. When ZFS is configured with > > > > > > `xattr=3Dsa`, xattrs are preferentially written into system att= ributes > > > > > > (SA). This was introduced IIRC primarily for performance reason= s > > > > > > This allows tiny xattrs (~100 bytes) to be stored with the dnod= e and > > > > > > up to 64 KiB of xattrs to be stored in the dnode spill block. I= f > > > > > > additional space is needed then they are written using the olde= r-style > > > > > > file-backed approach. > > > > > > > > > > > > What this means is that if someone is using this relatively com= mon > > > > > > configuration (the default in TrueNAS and in many Linux distros= ), then > > > > > > the result would be that only some xattrs written via extattr w= ould be > > > > > > visible by directly opening the ZFS attr dir. It would also int= roduce > > > > > > a mechanism whereby an xattr with the same name is written to t= wo > > > > > > different ZFS locations, which would potentially cause you to s= ee > > > > > > different xattr data depending on whether you read it from exta= ttr or > > > > > > via the attr dir. I don't know off-hand whether this could lead= to > > > > > > corruption / unexpected behavior in ZFS but if you haven't look= ed into > > > > > > it yet you may want to make sure you're properly handling the c= ase > > > > > > where someone has already written SA-backed xattrs. > > > > > I am in the process of defining a new setting for the xattr prope= rty > > > > > I've called "named" which would need to be set for the Solaris st= yle > > > > > extended attributes to work. > > > > > > > > > > I am making progress on the patch and am currently working throug= h > > > > > permissions (or authorization if you prefer). > > > > > > > > > > Here is what OpenZFS appears to do currently. > > > > > I am wondering if these sound reasonable for these attributes? > > > > > > > > > > - When an attr directory is created for a file object, the owners= hip > > > > > (uid and gid) is set to the same value as the file object. > > > > > The mode is set to 041777 (a directory with sticky bit set and > > > > > permissions for everyone. (It ignores the "mode" argument to > > > > > the open.) > > > > > --> As such, anyone who has access to the file object can acces= s > > > > > the extended attribute directory. > > > > > > > > Yes, that is the expected behaviour > > > > > > > > > > > > > > - When an attribute is created in the attribute directory, the ui= d is > > > > > set to that of the creating process (cr_uid), the gid is set t= o that > > > > > of the directory (which is also the gid of the file object). > > > > > The mode is set to that of a regular file with low order mode = bits > > > > > as specified by the "mode" argument to the openat() that crea= ted > > > > > it. > > > > > The mode can be changed with fchmod(2). > > > > > --> As such, access to each attribute file is controlled by the > > > > > attribute file's creator. > > > > > > > > > > Any comments on the above? > > > > > > > > Yes, that would be the expected behaviour. > > > > > > > > > > > > > > A couple of other questions... > > > > > - Should subdirectories of the attribute directory be supported? > > > > > I currently do not allow this, but it appears to be supportable > > > > > by both OpenZFS and NFSv4. > > > > > > > > No, please no subdirs for now. As far as I can see all consumes of > > > > such an API (Windows, MacOS etc) use flat layouts for the attribute > > > > and alternate data streams virtual dirs > > > > > > > > > > > > > > - Does restricting this support to ZFS file systems with the > > > > > xattr property set to "named" sound reasonable? > > > > > > > > What does that mean? > > > > Also, it should be "on" by default, both in FreeBSD ZFS, UFS and NF= S >=3D v4.1 > > > Hmm. I think (and the discussion with Andrew seemed to confirm it) > > > that they do not > > > mix well with FreeBSD/Linux style extended attributes. (For example, > > > the code that > > > checked access for the parent directory is disabled for FreeBSD style > > > attributes and > > > this is intentional, according to the comment.) > > > > > > Also, I doubt anyone will ever do support for UFS? (I am certainly no= t > > > volunteering.) > > > > > > The above means that a sysadmin will need to choose between which sty= le > > > of extended attributes they want on a "per file system basis" and tha= t FreeBSD > > > style will be the default, since to change that would be a POLA viola= tion, imho. > > > (If others feel that having the two styles co-exist on the same file > > > system is needed, > > > there might be a way to do it, but doing so properly won't be easy. > > > Another example > > > is naming. If both co-exist on the same file system, you can end up > > > with two different > > > attributes with the same name. I did this during testing, so I know i= t > > > can happen.) > > > > > > > > > > > > > > > > > Thanks for any comments, rick > > > > > ps: I have not, as yet, heard any comments w.r.t. whether or > > > > > not this should go into FreeBSD15. (No rush on this one, > > > > > but comments would be appreciated. > > > > > > > > I'd prefer the integration as soon as possible. > > > A couple of problems here. > > > 1 - You and Cedric are the only ones that have spoken up with support= for this. > > > (Having said that, no one has spoken up against it.) > > > 2 - Someone needs to do the "userspace" lifting at some point. > > > I haven't yet asked, so I do not know if you feel commands like = "chmod(1)" > > > need to be "named attribute aware"? (The fchmod(2) syscall works= , but > > > does the command line need to know how to do it? If yes, this is= work. > > > Probably more than I've spent getting the syscalls to work.) > > > 3 - A lot of the changes need to go into OpenZFS and I have no idea w= hat > > > their position will be? (Most of the changes are in the os/freeb= sd/zfs > > > source subtree, which may make it easier?) > > Oh, and another one... > > Testing. I have yet to hear from anyone trying to test the code. I obvi= ously > > do some testing, but my resources are limited. > > How can we do this? Grab patch, apply patch, build FreeBSD, install > new FreeBSD kernel? Yes. For now, only the kernel needs to be replaced. (I haven't yet quite figured out how to get the "zfs" command to set the new "named" value for the xattr property, so the patch always sets it (ok for testing only). Basically, install a recent FreeBSD snapshot of 15. If you go onto ftp.freebsd.org anonymous ftp, then cd into: pub/FreeBSD/snapshots/ISO-IMAGES/15.0 - You'll find a bunch of install images there. If you are installing on 64bit Intel (x86-64), you want one with "amd64" in the name. The ones I use have "disc1.iso" in the name. These are full install images that I burn onto a DVD. (I don't know what is convenient for newer hardware, but I'm sure someone will help if you can't figure out which one to use for the hardware/vm you are installing on.) Install it, including src. You'll need ZFS setup. This is covered in the handbook or you can just install a ZFS root fs for testing. Once this system is up, grab the patches and apply them to /usr/src. (If they don't apply cleanly, let me know and I can help. I am not tracking main/current and am using a Jan. snapshot.) Build/install a new kernel via (as root/su): # cd /usr/src # make buildkernel # make installkernel -> Reboot. # cp /usr/src/sys/sys/fcntl.h /usr/include/sys Now, you have to set up NFSv4. The basic steps are: - Create a /etc/exports. For testing one file system, 2 lines are needed. /filesystem -alldirs -maproot=3Droot V4: / (should be all you need for testing) Add the following lines to /etc/rc.conf: nfsuserd_enable=3D"YES" nfsuserd_flags=3D"-domain " nfs_server_enable=3D"YES" nfsv4_server_enable=3D"YES" nfsv4_server_only=3D"YES" - This should be sufficient for the NFSv4 server. To use the NFSv4 client, add: nfs_client_enable=3D"YES" nfscbd_enable=3D"YES" To do local testing of ZFS, you don't need the NFSv4 setup. Just cd into the ZFS file system and bash away at it. For both local testing and testing over NFSv4, you can start with https://people.freebsd.org/~rmacklem/xattrtest.c and work from there. > > The biggest issue for me is building and installing a new kernel in an > existing FreeBSD installation, or finding someone in-house who can do > that. > Howto or short blog post would be nice > > > > > For example, the pynfs test suite does have some xattr testing in it. > > However, I haven't used the pynfs test suite in a long time and am not > > a Python guy. It would be nice if someone else fired it up and did this > > testing. (If problems are found, I could probably track them down and > > fix them.) > > > > rick > > ps: In case you do not know, I am one guy who does this NFS stuff as > > a spare time hobby. I am not paid any $$$ by anyone to do it. > > Well, if you want a (NFS) job at CERN let me know (on-site, not remote). Thanks, but I am just shy of the big 70 and happily retired. rick > > Lionel From nobody Wed Mar 26 14:47:26 2025 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 4ZN8ld5z1Hz5s2rM; Wed, 26 Mar 2025 14:47:41 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZN8lc3DCVz46D7; Wed, 26 Mar 2025 14:47:40 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=G4m27Als; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rick.macklem@gmail.com designates 2a00:1450:4864:20::531 as permitted sender) smtp.mailfrom=rick.macklem@gmail.com Received: by mail-ed1-x531.google.com with SMTP id 4fb4d7f45d1cf-5e686d39ba2so13242762a12.2; Wed, 26 Mar 2025 07:47:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1743000459; x=1743605259; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=fio+mg6NqN92MNqEGQkUZJ7LX78RyYbJRV2DyfiK/G8=; b=G4m27Alsg2A5nuLsqe6WgDXVG456LfTohxHMvHOiTeRzQ6D8oCzAmYuFETAb1pvphM OaQ/zsW0qTdM2FJLrEiofCgK+v7tdA+lgCteAzY0cZ2IQG7pfo+XAfYiUqtM6K2KzG7g SCkTGaaUTN/a4GyiLWFnYEOBLDa3MxLEb4OaGqHsn4Npcl8M6y0oVDoYPMdpA45r4611 rulrCM9+bGg4mOLp0VjhxUOQali3qv+ovva/C1yMnfACGqzq0te8gWaWLIa7rEvfV/xJ 0fy6e/rMpjd1HvqQk/GhpPpDd7J+c6Ww51QmBAV+7nL/OMCYqomCEGUHAJmf5TJt/7dG tZAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743000459; x=1743605259; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=fio+mg6NqN92MNqEGQkUZJ7LX78RyYbJRV2DyfiK/G8=; b=rflGGiAEbBbGcmOygcoahfab1ewoXjnz4q/ce3h0ej9DU8VkJzP01u/0iayAO/+Imo ZgSoz7nDKEpzv0ADR2VR3IlqMnkjJXktN3eSS2r0szl1RB4FvvxKDFHlyHI99LFCFBOc oSFXV0H8sNPvOCuwbGQCQv42UzZUvlrDmcAd6y9kFcfA0YC9YuVtu0vOv/CbrwtplMwd 1z4UdqoHUVTQbjc+Ylq8WYAPnKJNrAm2oab1POQXJLPYMIrWcBRrQuAS9scuSLJ+0Kxa hQD8MdtMwcWbiqZckCn2dyQ28ZWxEdZQwf3QyG+tYvfh2o9avwUP/OEAGldw/y9bcpb1 /+OQ== X-Forwarded-Encrypted: i=1; AJvYcCX/gzf6fi79apufDiNAeBgkNL+bAHEvj6+BgeaZc8HyU6U1wE5mrx0VLJJ1yD2h4tkNvNyjXIt8BHD2SO8vm3JJ@freebsd.org, AJvYcCXC6yV2DgxMKNEa8JgnnsslzqENXh9UENwL+Kzi6Plm20K2BAs6Sqz8+ATQKekq+gM3/YmX@freebsd.org, AJvYcCXG72JCo/X896QAxwssBmUszqFVWHMSnKHucnlrsOBl+bwIySav2n6hh+XijhPus3rIwQKQ+9RwKA0T6Ys=@freebsd.org X-Gm-Message-State: AOJu0YxX1XFh3+ZtUpBOjFEpiG+K7f/4xaOeWq1kS9PhqKosLqJgks/L mgQL5FV0eXY9GqRES5knxOtKn+4EXTboAcLydDHZqjSo/3v2bwfkuyrBLYFY80f3eJ4O8jnSDXY LDxnFyQ4yF/vjXXbLDUN5XsVrKQ== X-Gm-Gg: ASbGncusHEEcUOtOS3y5Dajo0FV8LWQLtIIWCw0Bmk+epuvfqLQeRgXmQdyhSektEO0 WED2nA4Yh7rZwauS2CeDLmfxSnXlTBCp+II1WH8CXfUieS25i1zwaIlrMDE0/WKVrdfo4xu0sMm 75HfrGraWwog/7PgM3ECMF7znpE5M27E+fNBZtXw6iNYguRMbJOxwvfVmSIw== X-Google-Smtp-Source: AGHT+IGQf2mDgmC7M/LFFBLFEk/BhqW9bipN50Qe9mPpMT/sFt1PEry8BUJywN06oAhJXKO+aYTzLoFQMtTEvCM5mjg= X-Received: by 2002:a05:6402:35c4:b0:5e7:8efa:ba13 with SMTP id 4fb4d7f45d1cf-5ebcd40a6b3mr20238414a12.7.1743000458576; Wed, 26 Mar 2025 07:47:38 -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: In-Reply-To: From: Rick Macklem Date: Wed, 26 Mar 2025 07:47:26 -0700 X-Gm-Features: AQ5f1JqJ8TQw-qcA_cucbyltfl7hTh1s6YjNXlOJzli1jwVQhDuB0TdDMMbqysc Message-ID: Subject: Re: RFC: Solaris style extended attributes for FreeBSD To: Lionel Cons Cc: Andrew Walker , Konstantin Belousov , freebsd-arch@freebsd.org, FreeBSD CURRENT , Cedric Blancher Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Result: default: False [-2.46 / 15.00]; SUSPICIOUS_RECIPS(1.50)[]; NEURAL_HAM_LONG(-0.99)[-0.993]; NEURAL_HAM_SHORT(-0.99)[-0.993]; NEURAL_HAM_MEDIUM(-0.98)[-0.978]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; TO_DN_SOME(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TAGGED_FROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FREEMAIL_FROM(0.00)[gmail.com]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::531:from]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_CC(0.00)[ixsystems.com,freebsd.org,gmail.com]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org,freebsd-current@freebsd.org]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TAGGED_RCPT(0.00)[]; MISSING_XM_UA(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; RCPT_COUNT_FIVE(0.00)[6] X-Rspamd-Queue-Id: 4ZN8lc3DCVz46D7 X-Spamd-Bar: -- On Tue, Mar 25, 2025 at 2:14=E2=80=AFPM Rick Macklem wrote: > > On Tue, Mar 25, 2025 at 1:53=E2=80=AFPM Rick Macklem wrote: > > > > On Tue, Mar 25, 2025 at 12:06=E2=80=AFPM Lionel Cons wrote: > > > > > > On Sat, 22 Mar 2025 at 21:34, Rick Macklem w= rote: > > > > > > > > On Sun, Mar 9, 2025 at 5:38=E2=80=AFAM Andrew Walker wrote: > > > > > > > > > > > Since ZFS is already wired for them, adding the basics is prett= y > > > > > > straightforward. I am not suggesting that they should replace t= he > > > > > > current FreeBSD extended attributes > > > > > > > > > > The ZFS story is more complicated. When ZFS is configured with > > > > > `xattr=3Dsa`, xattrs are preferentially written into system attri= butes > > > > > (SA). This was introduced IIRC primarily for performance reasons > > > > > This allows tiny xattrs (~100 bytes) to be stored with the dnode = and > > > > > up to 64 KiB of xattrs to be stored in the dnode spill block. If > > > > > additional space is needed then they are written using the older-= style > > > > > file-backed approach. > > > > > > > > > > What this means is that if someone is using this relatively commo= n > > > > > configuration (the default in TrueNAS and in many Linux distros),= then > > > > > the result would be that only some xattrs written via extattr wou= ld be > > > > > visible by directly opening the ZFS attr dir. It would also intro= duce > > > > > a mechanism whereby an xattr with the same name is written to two > > > > > different ZFS locations, which would potentially cause you to see > > > > > different xattr data depending on whether you read it from extatt= r or > > > > > via the attr dir. I don't know off-hand whether this could lead t= o > > > > > corruption / unexpected behavior in ZFS but if you haven't looked= into > > > > > it yet you may want to make sure you're properly handling the cas= e > > > > > where someone has already written SA-backed xattrs. > > > > I am in the process of defining a new setting for the xattr propert= y > > > > I've called "named" which would need to be set for the Solaris styl= e > > > > extended attributes to work. > > > > > > > > I am making progress on the patch and am currently working through > > > > permissions (or authorization if you prefer). > > > > > > > > Here is what OpenZFS appears to do currently. > > > > I am wondering if these sound reasonable for these attributes? > > > > > > > > - When an attr directory is created for a file object, the ownershi= p > > > > (uid and gid) is set to the same value as the file object. > > > > The mode is set to 041777 (a directory with sticky bit set and > > > > permissions for everyone. (It ignores the "mode" argument to > > > > the open.) > > > > --> As such, anyone who has access to the file object can access > > > > the extended attribute directory. > > > > > > Yes, that is the expected behaviour > > > > > > > > > > > - When an attribute is created in the attribute directory, the uid = is > > > > set to that of the creating process (cr_uid), the gid is set to = that > > > > of the directory (which is also the gid of the file object). > > > > The mode is set to that of a regular file with low order mode bi= ts > > > > as specified by the "mode" argument to the openat() that create= d > > > > it. > > > > The mode can be changed with fchmod(2). > > > > --> As such, access to each attribute file is controlled by the > > > > attribute file's creator. > > > > > > > > Any comments on the above? > > > > > > Yes, that would be the expected behaviour. > > > > > > > > > > > A couple of other questions... > > > > - Should subdirectories of the attribute directory be supported? > > > > I currently do not allow this, but it appears to be supportable > > > > by both OpenZFS and NFSv4. > > > > > > No, please no subdirs for now. As far as I can see all consumes of > > > such an API (Windows, MacOS etc) use flat layouts for the attribute > > > and alternate data streams virtual dirs > > > > > > > > > > > - Does restricting this support to ZFS file systems with the > > > > xattr property set to "named" sound reasonable? > > > > > > What does that mean? > > > Also, it should be "on" by default, both in FreeBSD ZFS, UFS and NFS = >=3D v4.1 > > Hmm. I think (and the discussion with Andrew seemed to confirm it) > > that they do not > > mix well with FreeBSD/Linux style extended attributes. (For example, > > the code that > > checked access for the parent directory is disabled for FreeBSD style > > attributes and > > this is intentional, according to the comment.) > > > > Also, I doubt anyone will ever do support for UFS? (I am certainly not > > volunteering.) > > > > The above means that a sysadmin will need to choose between which style > > of extended attributes they want on a "per file system basis" and that = FreeBSD > > style will be the default, since to change that would be a POLA violati= on, imho. > > (If others feel that having the two styles co-exist on the same file > > system is needed, > > there might be a way to do it, but doing so properly won't be easy. > > Another example > > is naming. If both co-exist on the same file system, you can end up > > with two different > > attributes with the same name. I did this during testing, so I know it > > can happen.) > > > > > > > > > > > > > Thanks for any comments, rick > > > > ps: I have not, as yet, heard any comments w.r.t. whether or > > > > not this should go into FreeBSD15. (No rush on this one, > > > > but comments would be appreciated. > > > > > > I'd prefer the integration as soon as possible. > > A couple of problems here. > > 1 - You and Cedric are the only ones that have spoken up with support f= or this. > > (Having said that, no one has spoken up against it.) > > 2 - Someone needs to do the "userspace" lifting at some point. > > I haven't yet asked, so I do not know if you feel commands like "c= hmod(1)" > > need to be "named attribute aware"? (The fchmod(2) syscall works, = but > > does the command line need to know how to do it? If yes, this is w= ork. > > Probably more than I've spent getting the syscalls to work.) > > 3 - A lot of the changes need to go into OpenZFS and I have no idea wha= t > > their position will be? (Most of the changes are in the os/freebsd= /zfs > > source subtree, which may make it easier?) > Oh, and another one... > Testing. I have yet to hear from anyone trying to test the code. I obviou= sly > do some testing, but my resources are limited. > > For example, the pynfs test suite does have some xattr testing in it. > However, I haven't used the pynfs test suite in a long time and am not > a Python guy. It would be nice if someone else fired it up and did this > testing. (If problems are found, I could probably track them down and > fix them.) Oops, it sounds like pynfs tests the Linux/FreeBSD style extended attribute= s and not these (called named attributes in the NFSv4 RFCs). --> There is supposed to be support in Solaris, if anyone happens to have a Solaris installation handy. rick > > rick > ps: In case you do not know, I am one guy who does this NFS stuff as > a spare time hobby. I am not paid any $$$ by anyone to do it. > > > > > rick > > > > > > > > Lionel From nobody Wed Mar 26 15:43:55 2025 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 4ZNB0p6Thrz5s60K; Wed, 26 Mar 2025 15:44:10 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [IPv6:2a00:1450:4864:20::62a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZNB0n2mGfz3Z80; Wed, 26 Mar 2025 15:44:09 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=jMDZWz6f; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rick.macklem@gmail.com designates 2a00:1450:4864:20::62a as permitted sender) smtp.mailfrom=rick.macklem@gmail.com Received: by mail-ej1-x62a.google.com with SMTP id a640c23a62f3a-aaee2c5ee6eso1050679666b.1; Wed, 26 Mar 2025 08:44:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1743003846; x=1743608646; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=CjlYSRcS1k2+wU1YIDYyY4mND507im6IJG3Sx+eLytk=; b=jMDZWz6feWk1uQP/bVDanT6gOyoTtMo3uA44Z6fHe4NXRHPeKVOd3RY/AabpCV/pr6 n/H0KRQ0jxQtF/ab0MGapJS5aKTfiRSCVixuNrUIOrqZlR/8ZMZTLA7tkojX6l4Av7d/ eG0JmM+ylsZ/v5DFZHDh43GbTNvEqbY4NIAurYsX12H3IZRHuigQHz/JLF4Kt2kxzNui Cw7qQtwu53cLbqTvHrpSQj088vO4wXMoo/TSFxDEcV/PbuHyQe5k12oKj36U5YOk4Jja Q7090ZSRSNH5bGk7+gDZLaWYOQOddRpbIqhpZo9a0YOes6DaqNlzy+oBzBuLlHOfxCl3 xvsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743003846; x=1743608646; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=CjlYSRcS1k2+wU1YIDYyY4mND507im6IJG3Sx+eLytk=; b=SnpDNWFeC3AOOJQIFwbTn2NeSgRxfxmFqDTBpe1wqpdSv9Ap1LXocROIg6ft4ciQiU p1HnOwvea65FwR+DKHhwgHL4UULB7Gxp2DNKENBbezLK3T2O7wVRBewrAkJCkkuc/JwD UAufDUpdsmE8M88SB+42PXTDgqgXKWUyHzpoUdJEfPp3enQqivH95JDaKjb66kB+bHuz JeoelfcEd8xcWaQiFSijaeAJyoEOcaFKeghHvPo0vJikgZ3LdTLcjKs3TOeesnxAN+Ze 8zn7qt5des24HALsofZscKy49XO6yfg3+PJj3JBT6bOlIrNmu9I2MzGy5/nkhOG8DSwG mZUA== X-Forwarded-Encrypted: i=1; AJvYcCVot7JBwvmrH+aKFbp7sznbGSD3bluiNXt++B5IJXCXDVGSTbh+Sqj4tF7VmkkYiApNshP7@freebsd.org, AJvYcCWI9sv0B7R7ZWlCU6Ot3rc5NT3ksmx/GauwmGgepXzSE8cfRs5GjBGUJ6oPP2do3zSeuAf7orQEdlqBoM2VvggJ@freebsd.org, AJvYcCXOTxyrTRJXSNlZWIIRbeDMVWBHDFuYT0pFNCFLfi3c+ND0nRt1C/HOI+4V6uXPoYBBl3aV+tGjfqy+Vkc=@freebsd.org X-Gm-Message-State: AOJu0YzG+DvzGIHYNH7NzZkTJfenk6dzQCJO9kSGkAxkjUFInFoEIwMB Fp09h75t8tygEXbLREO5UlcAlQdn72w/DfeApPb22bV4ifpN/ElYORIgh5d6l9dLBIMgOIfLwHj oKocrrdDC+jas8PVA7SPvaIDiZA== X-Gm-Gg: ASbGncvaB9XwfhPRbySQgKkDyqyHsOaSGEmRBzp7UhfLOHo75xGuU7rhQrWsmbrwVjB kOmpp49HbHUy3Frs8yO0z5VV9Wi7A0o3lczquJnb5HE+oc5W3PBcBDSzwa3bV7N7tYR4z7vomdV 1Y/CwumFIdk8JTzzCt724HuRyUf0hdRsl8A4v3vAo5anbdmsC6s5pjKN8nGGlBfJ1Fui0E X-Google-Smtp-Source: AGHT+IEN/wp1Kq1NiXn8G6LCbpadDKkLZ+1jOwBcfom9ojmOimA7Cfjh/fTTtjkAGvCI7uWiiXcL01/wMAeiU2g4bGk= X-Received: by 2002:a17:906:6a0c:b0:ac3:8790:ce75 with SMTP id a640c23a62f3a-ac3f20b04c3mr2208645866b.10.1743003846087; Wed, 26 Mar 2025 08:44:06 -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: In-Reply-To: From: Rick Macklem Date: Wed, 26 Mar 2025 08:43:55 -0700 X-Gm-Features: AQ5f1JoCVBVV3Vw4L6bTOxmWaKHOgij1kpm8oBu-LUYS0EJUq87fXt8OVQFihQM Message-ID: Subject: Re: RFC: Solaris style extended attributes for FreeBSD To: Cedric Blancher Cc: Lionel Cons , Andrew Walker , Konstantin Belousov , freebsd-arch@freebsd.org, FreeBSD CURRENT Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Result: default: False [-2.41 / 15.00]; SUSPICIOUS_RECIPS(1.50)[]; NEURAL_HAM_LONG(-0.99)[-0.995]; NEURAL_HAM_MEDIUM(-0.99)[-0.986]; NEURAL_HAM_SHORT(-0.93)[-0.933]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; TO_DN_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62a:from]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; FREEMAIL_FROM(0.00)[gmail.com]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_FIVE(0.00)[6]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_CC(0.00)[gmail.com,ixsystems.com,freebsd.org]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org,freebsd-current@freebsd.org]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TAGGED_RCPT(0.00)[]; MISSING_XM_UA(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; FREEMAIL_ENVFROM(0.00)[gmail.com] X-Rspamd-Queue-Id: 4ZNB0n2mGfz3Z80 X-Spamd-Bar: -- On Wed, Mar 26, 2025 at 8:18=E2=80=AFAM Cedric Blancher wrote: > > On Wed, 26 Mar 2025 at 10:39, Lionel Cons wrot= e: > > > > On Tue, 25 Mar 2025 at 22:14, Rick Macklem wro= te: > > > > > > On Tue, Mar 25, 2025 at 1:53=E2=80=AFPM Rick Macklem wrote: > > > > > > > > On Tue, Mar 25, 2025 at 12:06=E2=80=AFPM Lionel Cons wrote: > > > > > > > > > > On Sat, 22 Mar 2025 at 21:34, Rick Macklem wrote: > > > > > > > > > > > > On Sun, Mar 9, 2025 at 5:38=E2=80=AFAM Andrew Walker wrote: > > > > > > > > > > > > > > > Since ZFS is already wired for them, adding the basics is p= retty > > > > > > > > straightforward. I am not suggesting that they should repla= ce the > > > > > > > > current FreeBSD extended attributes > > > > > > > > > > > > > > The ZFS story is more complicated. When ZFS is configured wit= h > > > > > > > `xattr=3Dsa`, xattrs are preferentially written into system a= ttributes > > > > > > > (SA). This was introduced IIRC primarily for performance reas= ons > > > > > > > This allows tiny xattrs (~100 bytes) to be stored with the dn= ode and > > > > > > > up to 64 KiB of xattrs to be stored in the dnode spill block.= If > > > > > > > additional space is needed then they are written using the ol= der-style > > > > > > > file-backed approach. > > > > > > > > > > > > > > What this means is that if someone is using this relatively c= ommon > > > > > > > configuration (the default in TrueNAS and in many Linux distr= os), then > > > > > > > the result would be that only some xattrs written via extattr= would be > > > > > > > visible by directly opening the ZFS attr dir. It would also i= ntroduce > > > > > > > a mechanism whereby an xattr with the same name is written to= two > > > > > > > different ZFS locations, which would potentially cause you to= see > > > > > > > different xattr data depending on whether you read it from ex= tattr or > > > > > > > via the attr dir. I don't know off-hand whether this could le= ad to > > > > > > > corruption / unexpected behavior in ZFS but if you haven't lo= oked into > > > > > > > it yet you may want to make sure you're properly handling the= case > > > > > > > where someone has already written SA-backed xattrs. > > > > > > I am in the process of defining a new setting for the xattr pro= perty > > > > > > I've called "named" which would need to be set for the Solaris = style > > > > > > extended attributes to work. > > > > > > > > > > > > I am making progress on the patch and am currently working thro= ugh > > > > > > permissions (or authorization if you prefer). > > > > > > > > > > > > Here is what OpenZFS appears to do currently. > > > > > > I am wondering if these sound reasonable for these attributes? > > > > > > > > > > > > - When an attr directory is created for a file object, the owne= rship > > > > > > (uid and gid) is set to the same value as the file object. > > > > > > The mode is set to 041777 (a directory with sticky bit set an= d > > > > > > permissions for everyone. (It ignores the "mode" argument to > > > > > > the open.) > > > > > > --> As such, anyone who has access to the file object can acc= ess > > > > > > the extended attribute directory. > > > > > > > > > > Yes, that is the expected behaviour > > > > > > > > > > > > > > > > > - When an attribute is created in the attribute directory, the = uid is > > > > > > set to that of the creating process (cr_uid), the gid is set= to that > > > > > > of the directory (which is also the gid of the file object). > > > > > > The mode is set to that of a regular file with low order mod= e bits > > > > > > as specified by the "mode" argument to the openat() that cr= eated > > > > > > it. > > > > > > The mode can be changed with fchmod(2). > > > > > > --> As such, access to each attribute file is controlled by the > > > > > > attribute file's creator. > > > > > > > > > > > > Any comments on the above? > > > > > > > > > > Yes, that would be the expected behaviour. > > > > > > > > > > > > > > > > > A couple of other questions... > > > > > > - Should subdirectories of the attribute directory be supported= ? > > > > > > I currently do not allow this, but it appears to be supportab= le > > > > > > by both OpenZFS and NFSv4. > > > > > > > > > > No, please no subdirs for now. As far as I can see all consumes o= f > > > > > such an API (Windows, MacOS etc) use flat layouts for the attribu= te > > > > > and alternate data streams virtual dirs > > > > > > > > > > > > > > > > > - Does restricting this support to ZFS file systems with the > > > > > > xattr property set to "named" sound reasonable? > > > > > > > > > > What does that mean? > > > > > Also, it should be "on" by default, both in FreeBSD ZFS, UFS and = NFS >=3D v4.1 > > > > Hmm. I think (and the discussion with Andrew seemed to confirm it) > > > > that they do not > > > > mix well with FreeBSD/Linux style extended attributes. (For example= , > > > > the code that > > > > checked access for the parent directory is disabled for FreeBSD sty= le > > > > attributes and > > > > this is intentional, according to the comment.) > > > > > > > > Also, I doubt anyone will ever do support for UFS? (I am certainly = not > > > > volunteering.) > > > > > > > > The above means that a sysadmin will need to choose between which s= tyle > > > > of extended attributes they want on a "per file system basis" and t= hat FreeBSD > > > > style will be the default, since to change that would be a POLA vio= lation, imho. > > > > (If others feel that having the two styles co-exist on the same fil= e > > > > system is needed, > > > > there might be a way to do it, but doing so properly won't be easy. > > > > Another example > > > > is naming. If both co-exist on the same file system, you can end up > > > > with two different > > > > attributes with the same name. I did this during testing, so I know= it > > > > can happen.) > > > > > > > > > > > > > > > > > > > > > Thanks for any comments, rick > > > > > > ps: I have not, as yet, heard any comments w.r.t. whether or > > > > > > not this should go into FreeBSD15. (No rush on this one, > > > > > > but comments would be appreciated. > > > > > > > > > > I'd prefer the integration as soon as possible. > > > > A couple of problems here. > > > > 1 - You and Cedric are the only ones that have spoken up with suppo= rt for this. > > > > (Having said that, no one has spoken up against it.) > > > > 2 - Someone needs to do the "userspace" lifting at some point. > > > > I haven't yet asked, so I do not know if you feel commands lik= e "chmod(1)" > > > > need to be "named attribute aware"? (The fchmod(2) syscall wor= ks, but > > > > does the command line need to know how to do it? If yes, this = is work. > > > > Probably more than I've spent getting the syscalls to work.) > > > > 3 - A lot of the changes need to go into OpenZFS and I have no idea= what > > > > their position will be? (Most of the changes are in the os/fre= ebsd/zfs > > > > source subtree, which may make it easier?) > > > Oh, and another one... > > > Testing. I have yet to hear from anyone trying to test the code. I ob= viously > > > do some testing, but my resources are limited. > > > > How can we do this? Grab patch, apply patch, build FreeBSD, install > > new FreeBSD kernel? > > > > The biggest issue for me is building and installing a new kernel in an > > existing FreeBSD installation, or finding someone in-house who can do > > that. > > Howto or short blog post would be nice > > @Rick: Can https://docs.freebsd.org/en/books/developers-handbook/kernelbu= ild/ > be used to built your patch? Not sure that still works? (At least, I think you need SRCTOP=3D/usr/src on the make command?) I'd just do "make buildkernel" when in the top level of the source tree. (You need the full source tree and not just kernel sources.) Then "make installkernel" will install it. --> If you want the kernel installed under a different name, you can.. # cd /usr/obj # cd down into GENERIC (can't remember all the subdirs in between) # make KERNEL=3D install Once you've done a "make buildkernel", you can do the same as above and use "make SRCTOP=3D/usr/src" to build a kernel again, but I'm not sure thats any easier than "make buildkernel" in /usr/src? rick > > Ced > -- > Cedric Blancher > [https://plus.google.com/u/0/+CedricBlancher/] > Institute Pasteur From nobody Wed Mar 26 18:36:45 2025 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 4ZNFr21HXDz5sGxh; Wed, 26 Mar 2025 18:36:50 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-yb1-xb2c.google.com (mail-yb1-xb2c.google.com [IPv6:2607:f8b0:4864:20::b2c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZNFr11KZNz40VP; Wed, 26 Mar 2025 18:36:49 +0000 (UTC) (envelope-from mavbsd@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=M4ye3Sqd; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=freebsd.org (policy=none); spf=pass (mx1.freebsd.org: domain of mavbsd@gmail.com designates 2607:f8b0:4864:20::b2c as permitted sender) smtp.mailfrom=mavbsd@gmail.com Received: by mail-yb1-xb2c.google.com with SMTP id 3f1490d57ef6-e637669ef11so177198276.1; Wed, 26 Mar 2025 11:36:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1743014208; x=1743619008; darn=freebsd.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date:message-id:reply-to; bh=x8NVc5V8PLba72XhwHcrsKUazwzAKiMEIBKBQ5y8ZRo=; b=M4ye3Sqd0ZyWEDbSdEw6RdzVRdDSFQsiCYGlUKT7OrdWDvcASxcSZ0keZGkLtEMFZ1 fjPgG1KZPftRUFjxOnuiKfmmdmX0YrJT+mVtr8IhPzj2YtAkOO2DA7aFuLdvwEjMoBnT jbJ9GEHXrA+LB8XjZ/J3xUQlnHdiwLZyvQU63HjbbbxhVNdgiN85C36UZxcDVxkJ0H/4 35evz2qENkIXAfszZF+Fu7E3E8/09HdIfNymBtS7eA/i7d6ZqfSEL8SblBZAKvGUK5lC v/CxmnM2wZ+k43F2tzfNiEmc6Tb/7ntu/2wMRLVgCDY6/I6XnMkGjVYDiqPAI/rNqUAV ZBrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743014208; x=1743619008; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=x8NVc5V8PLba72XhwHcrsKUazwzAKiMEIBKBQ5y8ZRo=; b=lUxtKoj80J8A3ggPz6YIFXENWzGvDXXjxG7AakaQWljZrYJZjx/o2n+nDpuXD4BXLQ dzt99kOOB1j40PAj9S/Ra+pr0ee0bXmZn2PETrEgHzGSbd82R1LZ/qyyebUqE+YqwxuC Hg8fvwXT/PpZhYR7OWHofIzuQUVvCXEdbni8bsg3GkVpbkcXpj4igAby7ZIyTYsJwXvz nkXwxu9BJIFulkQDNgnhuMBSUtiOFXOBYfQJthCHxyA9EyR6cnuRsTelvlyqAsIR9vcC AdAwoPlWoUuHQ7LlDCS8qNAWMg0mhaUpTBCRql6a7lRr+0BK6fMf5NxVmeGecGWCDegT Z7PQ== X-Forwarded-Encrypted: i=1; AJvYcCU+pBmPDDHMBaBW0SIhnAlI4juRUk0kH/jI5kT/q9rQfxcCOLlnrtIr3J97xzDHqjUcMErCIjfzjiMujV2vSscx@freebsd.org, AJvYcCVC3LMX5eJjP/j75dO90QmvLRniGbjTFYdV7LhTN2aPhEoT2HsDCXes5UvhFMBcbgFZ71iC@freebsd.org, AJvYcCXqJ44jrsWkehPzrSBokh5HTez8IW3jajyZsxDkUP5Nxf6Md9urkY8vWRptF76ng8svob7G8Oa6yZUM6FY=@freebsd.org X-Gm-Message-State: AOJu0YwXgSdd4W/AEwpnOVDJ8hscxv53hhjtxGndfK6C6csXnY+iRQK/ Gcktamcm5n/MW86TVaZfETjCNY1kWhJSVfyBNc2JDB0jSFU/XoXi X-Gm-Gg: ASbGnct0B5H9UeMoWSk4Xw9ml0NGFqUqfcGnUkpIooXQo6b7ygc8SvNUOW8i+SBDctK KgFh8yHIh+zM16WnNcpOph5VnDWy4PSuTNt0FclkThEgGS8mCW0K7wPDex8g/HJCyr0oumIMyB5 hnN/3DXHP94ssR1M83Cl4vhF3PJY7xmNC97SB+9GrJ+r3mpK1Klg9pqQUFzES6tj6J6zvmlkBsE sq7/RlMSGFWAfZOR/y4gxg994afcQ4DJhuxhbWvTJUk90fRFGSzOq1e09tGbevlco8nC7lv33g3 LriN5eQagk1WSYeeRwhR2NCuPTfokmXRzK1ciyhRgvC3 X-Google-Smtp-Source: AGHT+IGss/jn0LCQlB5SPSiuBfTy3s3G/2e2ZDrXD98XRCqW0cltpRUQ0x6Qx1r3iPsQrV9CN7bRsA== X-Received: by 2002:a05:6902:e03:b0:e63:7555:7a8 with SMTP id 3f1490d57ef6-e694353f06cmr947824276.5.1743014207711; Wed, 26 Mar 2025 11:36:47 -0700 (PDT) Received: from [10.230.45.5] ([38.32.73.2]) by smtp.gmail.com with ESMTPSA id 3f1490d57ef6-e66a4255713sm2647122276.21.2025.03.26.11.36.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 26 Mar 2025 11:36:47 -0700 (PDT) Message-ID: Date: Wed, 26 Mar 2025 14:36:45 -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 Thunderbird Subject: Re: RFC: Solaris style extended attributes for FreeBSD To: Rick Macklem , Lionel Cons Cc: Andrew Walker , Konstantin Belousov , freebsd-arch@freebsd.org, FreeBSD CURRENT , Cedric Blancher References: Content-Language: en-US From: Alexander Motin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Result: default: False [-3.06 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-0.99)[-0.994]; NEURAL_HAM_SHORT(-0.96)[-0.963]; FORGED_SENDER(0.30)[mav@FreeBSD.org,mavbsd@gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[text/plain]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : SPF not aligned (relaxed), DKIM not aligned (relaxed),none]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_TO(0.00)[gmail.com]; FREEMAIL_ENVFROM(0.00)[gmail.com]; TO_DN_SOME(0.00)[]; FREEMAIL_CC(0.00)[ixsystems.com,freebsd.org,gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_NEQ_ENVFROM(0.00)[mav@FreeBSD.org,mavbsd@gmail.com]; DKIM_TRACE(0.00)[gmail.com:+]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org,freebsd-current@freebsd.org]; RCPT_COUNT_SEVEN(0.00)[7]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TAGGED_RCPT(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::b2c:from] X-Rspamd-Queue-Id: 4ZNFr11KZNz40VP X-Spamd-Bar: --- Hi Rick, On 25.03.2025 16:53, Rick Macklem wrote: > 3 - A lot of the changes need to go into OpenZFS and I have no idea what > their position will be? (Most of the changes are in the os/freebsd/zfs > source subtree, which may make it easier?) I haven't looked on the patches yet, and I may not speak for the whole OpenZFS project, but I'd put emphasis on a cross-OS compatibility of the implementation, including the properties, namespace prefixes for different APIs, etc. Since the directory-style attributes are growing from Solaris, it would be nice if whatever API and on-disk format chosen would be compatible with it. Even though the merge traffic with Illumos is not that big lately and they are formally not a part of OpenZFS, but would be nice to not break the ties if possible. It might require some code archeology to understand the evolution of compatibility issues we have now. FreeBSD and Linux are equally important targets in OpenZFS now, and while some things might be difficult to implement on all platforms, for example Linux kernel does not support NFSv4-style ACLs, whatever design chosen should allow such perspective, even if not implemented immediately. So I am a little worried about "Most of the changes are in the os/freebsd/zfs source subtree". We don't want it to get implemented differently in Linux one day and become impossible to move pools between OS'es. We already have issues there, so would be good to not grow them. While formally not a part of OpenZFS tree (yet?), there are forks for Windows and MacOS. It would be cool to understand at least basic requirements of those systems. Don't get me wrong. I'd be really happy to see it done at least from the perspective of its being implemented for Solaris decades ago, and considering limitations other systems including FreeBSD have. It just might be a bit tangled after the years. -- Alexander Motin From nobody Wed Mar 26 20:16:20 2025 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 4ZNJ362KkWz5r8H8; Wed, 26 Mar 2025 20:16:34 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZNJ356Sjqz3yDX; Wed, 26 Mar 2025 20:16:33 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x52d.google.com with SMTP id 4fb4d7f45d1cf-5eb92df4fcbso426526a12.0; Wed, 26 Mar 2025 13:16:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1743020192; x=1743624992; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=mN5BBxJJZvuxG8jqugUJrewIHkiQibxDktjyPOzDGLI=; b=IYf6SVyvIT6It5ESL+ZMgiA4NwGJfFCgdMeSfRNlGfvNefeVgQ8f2xdOCcImx050ms d4CskTqIhyG/SX/0+AYkkyWg7LN4U8NAmvy5KeFz0hU4cevmMElBLxOdmX/+Xgj9eKbS TpAK3cSO9wpWZYru3rY2iZcGPCZ826w1CBa/p6gKTakUsmCmV3HL7eqMsic8qRR+dxah WmMiIthNszob21C6EcLw+ZcCFYc4uq0WzHpn+54DFnWgPKsrVyc0C47JIi9KYm2kYmTO ogyCUOqHBDbwhEY2JVQXNbP4Suplt/EZfZVJMbZY5Xce32QdiHSjm5bWtv183OsIqc2U ZQDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743020192; x=1743624992; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=mN5BBxJJZvuxG8jqugUJrewIHkiQibxDktjyPOzDGLI=; b=CtkU3V4p6HpsdkS/5vxcxYqZbh8mFHXVMvioGJSUHqFDVcOA/YmE43XzX0NGmRG23c Qu4FsxBKpVM8ONIB3Xss4JfnkE7GaVG78LAyKgcDJJIJwWgjuWYyxB+ZzEmRf6k+Y8vt ZoWR+dP0uyJiLe8Q1k/LEE4JtdVtvccYzOmA8YncG2lkbPKaHZ1z2Pc9Xt7wLKCbbSB+ wNMl5Zwv8VPUEf+nn/TanKVQD8+H2xvyq0hr6OtsfMyfsOoeXX6p/1rJLUxrSFUjCq+S drvDF4sUudsjhU+r/U4pyEUX5wA9gL5walKopTxwQLFoeqR4QkI/IDJdVrW4AmT1A4M1 Ct3A== X-Forwarded-Encrypted: i=1; AJvYcCUJZY+m9LeTrTl5pdntWE4f5Urknk4cJBQ/1LEDiBsAcRVosmqYntoMcLAM7gPSqCUjLOi2XSE6eZWRSylS4Icc@freebsd.org, AJvYcCV+cDxHHZzMDmfp+YxxOLZIC67ePBf43+a48L/HnV1zeALeoZ3vC233xop8SLTwSnERsdWP@freebsd.org, AJvYcCXfyyhzWLQtQhiN4GMkEvJs485Y8Q41rQ/vd1M2ZMkGr2LHVwCE0Wx+3u5+IFnvqL+J0YVyA+3m6kO1krg=@freebsd.org X-Gm-Message-State: AOJu0YxWgG05/HEBU6PifyECF98IV0UEdQlFKaS2I72mMgZuqIhZD7Xd 4y6PS9gbmliTaZr63fHr18XXuMGztaE6sLCW0dHQF/32f63McOVp7AsQMQVWVEyARK5odI4UF5A 4fE3n6Y9NlzyJse6aZ2WlnGngglHA X-Gm-Gg: ASbGncsPcnuXw1FhyoAapMagBJ8fPljxVkFnxRRufmsv5LuPmPZMEXRU2txSKc0xNrd /ZPs1HfuZemJcYTnfmzIJahvRhphhBhwCE0JcvfozjHYQ7FBEw+0SlF+Qc/nGzdEE6LLSoi2yTU cqwmIsAOx3G2m/wOZr6I/kTO++/H0JH+EQYCjJLfZd135PFcvIez9eHAn2Ag== X-Google-Smtp-Source: AGHT+IHN/MO9IvEx+J+WkGVE/V6zS8ZnQNNV2BeSbcS1AXiGaVwPaMYeZw/elwP8dY8go6DMaNA7meBrEH10wKeqiFc= X-Received: by 2002:a05:6402:234c:b0:5dc:c9ce:b022 with SMTP id 4fb4d7f45d1cf-5ed8e382771mr808175a12.9.1743020192023; Wed, 26 Mar 2025 13:16:32 -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: In-Reply-To: From: Rick Macklem Date: Wed, 26 Mar 2025 13:16:20 -0700 X-Gm-Features: AQ5f1JojEECNvvWvYS-RFCAl-_B8H3e_etIP3RvpKNcCXaK_QMiKrFOlirJegYE Message-ID: Subject: Re: RFC: Solaris style extended attributes for FreeBSD To: Alexander Motin Cc: Lionel Cons , Andrew Walker , Konstantin Belousov , freebsd-arch@freebsd.org, FreeBSD CURRENT , Cedric Blancher Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[]; TAGGED_RCPT(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Queue-Id: 4ZNJ356Sjqz3yDX X-Spamd-Bar: ---- On Wed, Mar 26, 2025 at 11:36=E2=80=AFAM Alexander Motin = wrote: > > Hi Rick, > > On 25.03.2025 16:53, Rick Macklem wrote: > > 3 - A lot of the changes need to go into OpenZFS and I have no idea wha= t > > their position will be? (Most of the changes are in the os/freebs= d/zfs > > source subtree, which may make it easier?) > > I haven't looked on the patches yet, and I may not speak for the whole > OpenZFS project, but I'd put emphasis on a cross-OS compatibility of the > implementation, including the properties, namespace prefixes for > different APIs, etc. > > Since the directory-style attributes are growing from Solaris, it would > be nice if whatever API and on-disk format chosen would be compatible > with it. Even though the merge traffic with Illumos is not that big > lately and they are formally not a part of OpenZFS, but would be nice to > not break the ties if possible. It might require some code archeology > to understand the evolution of compatibility issues we have now. As far as on-disk, I have done nothing. The patches just use what is alread= y there. As for the API, I am not familiar with what solaris did, since that seems to have been stripped out? (I can see from man pages that the syscall interface uses O_XATTR, but I do not see any indication how that might land in ZFS? I suppose I can dive into Illumos sources, but I'll admit I am not excited by the prospect.;-) The big question I see is whether these attributes (or the API to get at them, if you prefer) should co-exist with the Linux/FreeBSD style on the same file system? If I understand the code (I may not), the Linux/FreeBSD style extended attributes are layered on top of the Solaris style ones stored in ZFS. There are some quirks that I haven't quite figured out yet. - How does the Linux/FreeBSD style determine attrnamespace? (I think it might be done via a "user." or "system." prefix, but I haven'= t figured it out yet?) - For FreeBSD, the code (in zfs_zaccess()) just punts, then calls like zfs_setextattr() which implement the VOP kapi use FreeBSD generic functions like exattr_check_cred() to do the checking. --> I ended up cribbing the code from the Linux side to do the checking in zfs_zaccess() for the Solaris style attributes. The problem is...zfs_zaccess() must decide whether or not to punt. --> As such, I have currently coded it so that the two styles do no co-exit on the same file system. I have succeeded in creating two attributes that show up with the same name (one created via zfs_setextattr() and the other via the named attribute syscall. So, I need to keep working on this.;-) > > FreeBSD and Linux are equally important targets in OpenZFS now, and > while some things might be difficult to implement on all platforms, for > example Linux kernel does not support NFSv4-style ACLs, whatever design > chosen should allow such perspective, even if not implemented > immediately. So I am a little worried about "Most of the changes are in > the os/freebsd/zfs source subtree". We don't want it to get implemented > differently in Linux one day and become impossible to move pools between > OS'es. We already have issues there, so would be good to not grow them. All I've seen w.r.t. the Linux side was a discussion (dated 2016) where the= y discussed the possibility of using an ioctl() API for doing this. As far as I know, nothing came of it. Most of the ZFS changes are FreeBSD specific, since they involve the FreeBSD VOP_LOOKUP(), which is definitely FreeBSD specific. (One weirdness is that ".." in these named attribute directories refers to the file object the attributes are associated with. As such, ".." often refers to a non-directory. This is what the ZFS code does and is mentioned in the NFSv4 RFC, with a SHOULD. (In NFSv4, "..' doesn't exist, but is accessed via the lookup parent operation.) > > While formally not a part of OpenZFS tree (yet?), there are forks for > Windows and MacOS. It would be cool to understand at least basic > requirements of those systems. My vague understanding is that both of these do something close to Solaris style, although I can never remember their terminology. A couple of the guys in this discussion might be able to help w.r.t. Windows, since I think their interest is related to a Windows NFSv4.1 client. Anyone able to comment? > > Don't get me wrong. I'd be really happy to see it done at least from > the perspective of its being implemented for Solaris decades ago, and > considering limitations other systems including FreeBSD have. It just > might be a bit tangled after the years. The current patch https://people.freebsd.org/~rmacklem/xattr.patch isn't particularly large and is really just the API rigging which basically seems to work. It has a bunch of printf()s in it which make it a little hard to read and does not yet try to make ZFS build for systems without the rest of the patch. Maybe you would find it easy to take a look at? rick > > -- > Alexander Motin From nobody Wed Mar 26 20:45:15 2025 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 4ZNJhV5FWFz5r9bl; Wed, 26 Mar 2025 20:45:30 +0000 (UTC) (envelope-from rick.macklem@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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZNJhT53Hzz3L5N; Wed, 26 Mar 2025 20:45:29 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=DpvheaEE; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rick.macklem@gmail.com designates 2a00:1450:4864:20::532 as permitted sender) smtp.mailfrom=rick.macklem@gmail.com Received: by mail-ed1-x532.google.com with SMTP id 4fb4d7f45d1cf-5e5e0caa151so463838a12.0; Wed, 26 Mar 2025 13:45:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1743021927; x=1743626727; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=sr3YFov4BK2aTNvFd813PJ6MLOn0vE3kzg2fcZoBPhI=; b=DpvheaEEcEgMG/vRT7M8F8Z2rNu2Uq3inel1Ag2huC/qPE9/Q1vuEqrhdn8lSDAv0a bYmq5zErdJBdB0xBDLzMB8MbHXQ5lWmCyRpIsRA828ZOoqgbZt16GRxs3yCgTCA//Z/P jcGDFYRxIpksaAorYsmXLqmZ/F8lNhEfeFOdffIialfd/0+Oom99X15HPDCXofn/fOGg eeBHK5jElTlhwHSG/B58b+OUF7iSgOLaYuWA1qp+XGAgoSBPLSKHDuTmqvBbxC96ir3F sTehhR5zCMLReAYyhG3l/695IIzkkuZ/U7cwN23z+Sg5j5dOrPB6vPufLSCaZQPj/7gb 1JVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743021927; x=1743626727; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=sr3YFov4BK2aTNvFd813PJ6MLOn0vE3kzg2fcZoBPhI=; b=wIg0ERYhpgyUFShnXR0eMSMceB5fpL58gPsecN3QRoY/ue/rMU+KjmKDw1ft6CbMZ/ EE280vUg3sSDzDJzNFgfEl6AveQG9QpkGU0kydbXPpNXGampyNidPX9W3/8U2kl3u6yg doHL3CAaTwmu4CZ18BIyzA5gRufR63hLGrvVUeECR1L+oy/Whv7yzbvjdyTz81BNmtFe HAZyHHvIgBsjMgWTg/cWuoI5J92/NoekMjPb6jJW7xHCw+jPOmbKjwcYXOWcD1BFJ/s7 K45YZBgHamSsUJA6H2yLDAApCb65BYN3yLsz8dAOX3Gv6SCLMgfiOsAGqIFLaD6GUIUR b7qw== X-Forwarded-Encrypted: i=1; AJvYcCVZ0gnUQHqPMY+iO/VPupI50kx5ldfUVygkeToDepEzl5xylZhxwtY/95kU9qFWiDxvvLOt@freebsd.org, AJvYcCXH9TtP/QZoOhcVXWDMcTe5HDsl+UD1Lyuppvt2lIuwegvtbJRjtyel4GPhdvh+wkW3uCmvWqex2bFLOFAGesHu@freebsd.org, AJvYcCXjUV1mSmjJuRLzVB2gJ/NgXadTeJ0duvDyXSuKmVXnrhOlea+I71ps8lPwE/JO5O1s3zRjnbJSiMrYn30=@freebsd.org X-Gm-Message-State: AOJu0Yy+cjaKa1b7F5mdBQ0GvMgKAfIpH7CCWM7vSymJXBsOLdiJ+0oT lQDttRGW0hrNdd3BcBw1CQNuckHGK9AbRFQr0reAG/NTmCSB3eN6vfu2ad8dKqBzM8cbFZM40wY RNfw7nAScJ0fGDvuRzhnYJ2hth3K6Ws8= X-Gm-Gg: ASbGncsCqPN6BXtgtmWHstFnOs77FmBSGJ1QoPcOnvd6ZlId1QMbnXLoTcFNpcYxw66 kshQyrZGGTSIGXm/f38f52xIuZt+e0wE4b1n6SBrHtscP7qiFLi8Fz+us33DpOZsYPH8AFisG41 PQxA6l/UNe4w3dVLvMINbOGGtqHi9mxXbsNHMwJ0gxLNYm70536pN2R08RPg== X-Google-Smtp-Source: AGHT+IEqnB1NSoH6Qf4c/i1gGgoM+OZ8vvZ6LhkC/7vyRNg9rsUZRoVkR7E/hCl3Tit9njTDic3iQNC4K+q6+DeIjmc= X-Received: by 2002:a05:6402:42c2:b0:5ec:c982:7efe with SMTP id 4fb4d7f45d1cf-5ed8e59ddbamr1018244a12.14.1743021926769; Wed, 26 Mar 2025 13:45:26 -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: In-Reply-To: From: Rick Macklem Date: Wed, 26 Mar 2025 13:45:15 -0700 X-Gm-Features: AQ5f1JqNFA8wl39U2RBykJ6RW3AU8aH7uZk-me3zQ7bMY1YouGF9wo0xhHA17n0 Message-ID: Subject: Re: RFC: Solaris style extended attributes for FreeBSD To: Alexander Motin Cc: Lionel Cons , Andrew Walker , Konstantin Belousov , freebsd-arch@freebsd.org, FreeBSD CURRENT , Cedric Blancher Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Result: default: False [-2.42 / 15.00]; SUSPICIOUS_RECIPS(1.50)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-0.99)[-0.993]; NEURAL_HAM_SHORT(-0.93)[-0.932]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[text/plain]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_TLS_LAST(0.00)[]; TO_DN_SOME(0.00)[]; ARC_NA(0.00)[]; FREEMAIL_CC(0.00)[gmail.com,ixsystems.com,freebsd.org]; MIME_TRACE(0.00)[0:+]; FROM_HAS_DN(0.00)[]; MISSING_XM_UA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org,freebsd-current@freebsd.org]; TAGGED_RCPT(0.00)[]; RCPT_COUNT_SEVEN(0.00)[7]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::532:from] X-Rspamd-Queue-Id: 4ZNJhT53Hzz3L5N X-Spamd-Bar: -- On Wed, Mar 26, 2025 at 1:16=E2=80=AFPM Rick Macklem wrote: > > On Wed, Mar 26, 2025 at 11:36=E2=80=AFAM Alexander Motin wrote: > > > > Hi Rick, > > > > On 25.03.2025 16:53, Rick Macklem wrote: > > > 3 - A lot of the changes need to go into OpenZFS and I have no idea w= hat > > > their position will be? (Most of the changes are in the os/free= bsd/zfs > > > source subtree, which may make it easier?) > > > > I haven't looked on the patches yet, and I may not speak for the whole > > OpenZFS project, but I'd put emphasis on a cross-OS compatibility of th= e > > implementation, including the properties, namespace prefixes for > > different APIs, etc. > > > > Since the directory-style attributes are growing from Solaris, it would > > be nice if whatever API and on-disk format chosen would be compatible > > with it. Even though the merge traffic with Illumos is not that big > > lately and they are formally not a part of OpenZFS, but would be nice t= o > > not break the ties if possible. It might require some code archeology > > to understand the evolution of compatibility issues we have now. > As far as on-disk, I have done nothing. The patches just use what is alre= ady > there. > > As for the API, I am not familiar with what solaris did, since that > seems to have been stripped out? (I can see from man pages that the > syscall interface uses O_XATTR, but I do not see any indication how > that might land in ZFS? I suppose I can dive into Illumos sources, > but I'll admit I am not excited by the prospect.;-) > > The big question I see is whether these attributes (or the API to get at > them, if you prefer) should co-exist with the Linux/FreeBSD style on the > same file system? > > If I understand the code (I may not), the Linux/FreeBSD style extended > attributes are layered on top of the Solaris style ones stored in ZFS. > There are some quirks that I haven't quite figured out yet. > - How does the Linux/FreeBSD style determine attrnamespace? > (I think it might be done via a "user." or "system." prefix, but I have= n't > figured it out yet?) Ok, I just figured out a little more of this for the FreeBSD case... When zfs_xattr_compat is set (which is the case in the code now), the userspace attributes do not get any prefix.(This appears to be meant to be compatible with Solaris, but not Linux?) With zfs_xattr_compat zero, it prefixes "user.", which does appear to be Linux compatible? For system space, it puts "freebsd:system:" as a prefix. Definitely FreeBSD specific. It seems that FreeBSD's naming can be Solaris compatible for user space, but I still do not know how I got a duplicate name? (The code already appears to know to ignore the system space ones that start with "freebsd:system:" for the attribute directory stuff.) rick > - For FreeBSD, the code (in zfs_zaccess()) just punts, then calls like > zfs_setextattr() which implement the VOP kapi use FreeBSD generic > functions like exattr_check_cred() to do the checking. > --> I ended up cribbing the code from the Linux side to do the checking > in zfs_zaccess() for the Solaris style attributes. > The problem is...zfs_zaccess() must decide whether or not to punt. > --> As such, I have currently coded it so that the two styles do no > co-exit on the same file system. > I have succeeded in creating two attributes that show up with the > same name (one created via zfs_setextattr() and the other via the > named attribute syscall. So, I need to keep working on this.;-) > > > > > FreeBSD and Linux are equally important targets in OpenZFS now, and > > while some things might be difficult to implement on all platforms, for > > example Linux kernel does not support NFSv4-style ACLs, whatever design > > chosen should allow such perspective, even if not implemented > > immediately. So I am a little worried about "Most of the changes are i= n > > the os/freebsd/zfs source subtree". We don't want it to get implemente= d > > differently in Linux one day and become impossible to move pools betwee= n > > OS'es. We already have issues there, so would be good to not grow them= . > All I've seen w.r.t. the Linux side was a discussion (dated 2016) where t= hey > discussed the possibility of using an ioctl() API for doing this. > As far as I know, nothing came of it. > > Most of the ZFS changes are FreeBSD specific, since they involve > the FreeBSD VOP_LOOKUP(), which is definitely FreeBSD specific. > (One weirdness is that ".." in these named attribute directories refers > to the file object the attributes are associated with. As such, ".." ofte= n > refers to a non-directory. This is what the ZFS code does and is > mentioned in the NFSv4 RFC, with a SHOULD. (In NFSv4, "..' doesn't > exist, but is accessed via the lookup parent operation.) > > > > > While formally not a part of OpenZFS tree (yet?), there are forks for > > Windows and MacOS. It would be cool to understand at least basic > > requirements of those systems. > My vague understanding is that both of these do something close to > Solaris style, although I can never remember their terminology. > A couple of the guys in this discussion might be able to help w.r.t. > Windows, since I think their interest is related to a Windows NFSv4.1 > client. Anyone able to comment? > > > > > Don't get me wrong. I'd be really happy to see it done at least from > > the perspective of its being implemented for Solaris decades ago, and > > considering limitations other systems including FreeBSD have. It just > > might be a bit tangled after the years. > The current patch > https://people.freebsd.org/~rmacklem/xattr.patch > isn't particularly large and is really just the API rigging > which basically seems to work. > It has a bunch of printf()s in it which make it a little hard to read > and does not yet try to make ZFS build for systems without the > rest of the patch. > > Maybe you would find it easy to take a look at? rick > > > > > -- > > Alexander Motin From nobody Wed Mar 26 23:05:34 2025 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 4ZNMpN2mjGz5rLJP; Wed, 26 Mar 2025 23:05:48 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZNMpM2jGrz3QyQ; Wed, 26 Mar 2025 23:05:47 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=Rc4vAPkT; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rick.macklem@gmail.com designates 2a00:1450:4864:20::531 as permitted sender) smtp.mailfrom=rick.macklem@gmail.com Received: by mail-ed1-x531.google.com with SMTP id 4fb4d7f45d1cf-5dccaaca646so724752a12.0; Wed, 26 Mar 2025 16:05:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1743030345; x=1743635145; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=o+oLB2GNxgriqy+EeEpVqOQ31KGAfaWQ4mI/0+VQp/A=; b=Rc4vAPkTefSxayK6vmbFhKVp9r5M9NZS9bcmFPeR02TQz9uVR6DEybN7N7rylpL9sG vw0hzp5vEiumfjeDBwiJn6y6vmghWo+PvRooQ7b17O+jBzlHo9cro/oj808VfoNOd/1g LHkWRmpQqe9PpuTusdQH+ZDtVcbpnUUqLtsaYmI9jET1kz+YvDZDc5EoSB2pApRDnmre AYOpIqJ93/Ic8ayI2RAwinCHurqPlcaTfitR7npbTtnbLVJsegzbUngTGlwW9/yjBwQP Z/PhYaqbVqRQXHrKVnjjdMfDuQVeEeLs2GIJnTxjDoVW6ccZIXtbQxgzGH89StWTNdIP Ruuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743030345; x=1743635145; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=o+oLB2GNxgriqy+EeEpVqOQ31KGAfaWQ4mI/0+VQp/A=; b=TU0UyOz2OGZfdiT7dzAfRyykHn5varPjVXXIV8TCK9lZ4BHTuAaYzAd1SKPJQ6PSQM 67BuODjTVrVju4p9T7zlfXg2ya7z4ASS6nZ73YGqt6GNpRSfbKh7TWFp/Bs8M7Q3BtUq ugo3sK4Mj5UclJrxgxxZwPV6xRkiA+3FTwMlxOEwHAOgcosv5f7JD/K8Evme0ztkzvfv 2MQQ69AhGldboMUYASlsngqQ3nM/UEuX73f4dF4BxfPCKOFb8pQrWeFTXEvexMBPX5GF 2NfnjdlsK629Kmh9bacHBIMA6kRvNeAyGbdn3d5DRzJh/7vwSWiQqzpiSGBXIpysEpSs HmKQ== X-Forwarded-Encrypted: i=1; AJvYcCVtDTHyLGqSoDDKMB/GgU4XbGb7IWLQhw0xzgXyFKFY5q5NBHfrOWPm1kLn7KAka1wPFlm+@freebsd.org, AJvYcCVvb3TxsvQ5QNZ+IJvZC7R/WuwLC1mg/ghO09WeF1B6mRtFv4keo1ar9gThOntjVhZiHN6gh+dF2DLRpyc=@freebsd.org, AJvYcCXTwgqfQsLo4DnKnXR4XzwKde4F83v5I6xKvmJN8T2S1UMU+iXA9JJCwVhEIK/184FnmNdEpfg7oevYW8AQ82rb@freebsd.org X-Gm-Message-State: AOJu0YwznoaYbEOWjJ043jP9kP8fCyrJPWtdac/xTzOVdbjshu10sZAm tL9trXTlh/kbRzWFAJMVbbG0tHpwnaggQnng756XsjJxq4SNYFkEeRS9aLIYBI+PKjqLVIBMrQI VVSPq6tn4ueef2nGxI2vLjv/bpw== X-Gm-Gg: ASbGncue5tjEp/Cy3+8U8IF7G0qKu+CgjTswZtXSmuEq6Cu8+df0yUvPNbolZ/CyvWt SMffKAS8PkYXBMBCat+j9lm+eY/Yl9L50KSVeFQhV2m4enu+5frB7P/YgJFo/G3FG4XWlCvZuPN SvGd0suOpk1P0RtCHoPt2GMnr45zXuSVGs2Jr9u3Conj2yBjzpCxLYtZsmkw== X-Google-Smtp-Source: AGHT+IGiX5jcGz0LQtKvMPJBWhwAeJLIJX000YCFHgb+X2ENVOUG1+TMr748BbOVmoQ6EFV34myyRrz77ms6Rp2MlUE= X-Received: by 2002:a05:6402:27c6:b0:5ed:5cf6:e168 with SMTP id 4fb4d7f45d1cf-5ed8a2eccc4mr1473812a12.9.1743030345169; Wed, 26 Mar 2025 16:05:45 -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: In-Reply-To: From: Rick Macklem Date: Wed, 26 Mar 2025 16:05:34 -0700 X-Gm-Features: AQ5f1JqVFoKmDeMn45nktPTVOOT3rQmaDgUIZjjAu9KzQHSMIpWapJuJLadi7S0 Message-ID: Subject: Re: RFC: Solaris style extended attributes for FreeBSD To: Lionel Cons Cc: Andrew Walker , Konstantin Belousov , freebsd-arch@freebsd.org, FreeBSD CURRENT , Cedric Blancher Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Result: default: False [-2.21 / 15.00]; SUSPICIOUS_RECIPS(1.50)[]; NEURAL_HAM_LONG(-1.00)[-0.999]; NEURAL_HAM_MEDIUM(-0.89)[-0.890]; NEURAL_HAM_SHORT(-0.82)[-0.820]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; MIME_GOOD(-0.10)[text/plain]; TAGGED_FROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::531:from]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; FREEMAIL_TO(0.00)[gmail.com]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+]; TO_DN_SOME(0.00)[]; FREEMAIL_CC(0.00)[ixsystems.com,freebsd.org,gmail.com]; MISSING_XM_UA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; TAGGED_RCPT(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org,freebsd-current@freebsd.org]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCPT_COUNT_FIVE(0.00)[6] X-Rspamd-Queue-Id: 4ZNMpM2jGrz3QyQ X-Spamd-Bar: -- On Wed, Mar 26, 2025 at 7:43=E2=80=AFAM Rick Macklem wrote: > > On Wed, Mar 26, 2025 at 2:39=E2=80=AFAM Lionel Cons wrote: > > > > On Tue, 25 Mar 2025 at 22:14, Rick Macklem wro= te: > > > > > > On Tue, Mar 25, 2025 at 1:53=E2=80=AFPM Rick Macklem wrote: > > > > > > > > On Tue, Mar 25, 2025 at 12:06=E2=80=AFPM Lionel Cons wrote: > > > > > > > > > > On Sat, 22 Mar 2025 at 21:34, Rick Macklem wrote: > > > > > > > > > > > > On Sun, Mar 9, 2025 at 5:38=E2=80=AFAM Andrew Walker wrote: > > > > > > > > > > > > > > > Since ZFS is already wired for them, adding the basics is p= retty > > > > > > > > straightforward. I am not suggesting that they should repla= ce the > > > > > > > > current FreeBSD extended attributes > > > > > > > > > > > > > > The ZFS story is more complicated. When ZFS is configured wit= h > > > > > > > `xattr=3Dsa`, xattrs are preferentially written into system a= ttributes > > > > > > > (SA). This was introduced IIRC primarily for performance reas= ons > > > > > > > This allows tiny xattrs (~100 bytes) to be stored with the dn= ode and > > > > > > > up to 64 KiB of xattrs to be stored in the dnode spill block.= If > > > > > > > additional space is needed then they are written using the ol= der-style > > > > > > > file-backed approach. > > > > > > > > > > > > > > What this means is that if someone is using this relatively c= ommon > > > > > > > configuration (the default in TrueNAS and in many Linux distr= os), then > > > > > > > the result would be that only some xattrs written via extattr= would be > > > > > > > visible by directly opening the ZFS attr dir. It would also i= ntroduce > > > > > > > a mechanism whereby an xattr with the same name is written to= two > > > > > > > different ZFS locations, which would potentially cause you to= see > > > > > > > different xattr data depending on whether you read it from ex= tattr or > > > > > > > via the attr dir. I don't know off-hand whether this could le= ad to > > > > > > > corruption / unexpected behavior in ZFS but if you haven't lo= oked into > > > > > > > it yet you may want to make sure you're properly handling the= case > > > > > > > where someone has already written SA-backed xattrs. > > > > > > I am in the process of defining a new setting for the xattr pro= perty > > > > > > I've called "named" which would need to be set for the Solaris = style > > > > > > extended attributes to work. > > > > > > > > > > > > I am making progress on the patch and am currently working thro= ugh > > > > > > permissions (or authorization if you prefer). > > > > > > > > > > > > Here is what OpenZFS appears to do currently. > > > > > > I am wondering if these sound reasonable for these attributes? > > > > > > > > > > > > - When an attr directory is created for a file object, the owne= rship > > > > > > (uid and gid) is set to the same value as the file object. > > > > > > The mode is set to 041777 (a directory with sticky bit set an= d > > > > > > permissions for everyone. (It ignores the "mode" argument to > > > > > > the open.) > > > > > > --> As such, anyone who has access to the file object can acc= ess > > > > > > the extended attribute directory. > > > > > > > > > > Yes, that is the expected behaviour > > > > > > > > > > > > > > > > > - When an attribute is created in the attribute directory, the = uid is > > > > > > set to that of the creating process (cr_uid), the gid is set= to that > > > > > > of the directory (which is also the gid of the file object). > > > > > > The mode is set to that of a regular file with low order mod= e bits > > > > > > as specified by the "mode" argument to the openat() that cr= eated > > > > > > it. > > > > > > The mode can be changed with fchmod(2). > > > > > > --> As such, access to each attribute file is controlled by the > > > > > > attribute file's creator. > > > > > > > > > > > > Any comments on the above? > > > > > > > > > > Yes, that would be the expected behaviour. > > > > > > > > > > > > > > > > > A couple of other questions... > > > > > > - Should subdirectories of the attribute directory be supported= ? > > > > > > I currently do not allow this, but it appears to be supportab= le > > > > > > by both OpenZFS and NFSv4. > > > > > > > > > > No, please no subdirs for now. As far as I can see all consumes o= f > > > > > such an API (Windows, MacOS etc) use flat layouts for the attribu= te > > > > > and alternate data streams virtual dirs > > > > > > > > > > > > > > > > > - Does restricting this support to ZFS file systems with the > > > > > > xattr property set to "named" sound reasonable? > > > > > > > > > > What does that mean? > > > > > Also, it should be "on" by default, both in FreeBSD ZFS, UFS and = NFS >=3D v4.1 > > > > Hmm. I think (and the discussion with Andrew seemed to confirm it) > > > > that they do not > > > > mix well with FreeBSD/Linux style extended attributes. (For example= , > > > > the code that > > > > checked access for the parent directory is disabled for FreeBSD sty= le > > > > attributes and > > > > this is intentional, according to the comment.) > > > > > > > > Also, I doubt anyone will ever do support for UFS? (I am certainly = not > > > > volunteering.) > > > > > > > > The above means that a sysadmin will need to choose between which s= tyle > > > > of extended attributes they want on a "per file system basis" and t= hat FreeBSD > > > > style will be the default, since to change that would be a POLA vio= lation, imho. > > > > (If others feel that having the two styles co-exist on the same fil= e > > > > system is needed, > > > > there might be a way to do it, but doing so properly won't be easy. > > > > Another example > > > > is naming. If both co-exist on the same file system, you can end up > > > > with two different > > > > attributes with the same name. I did this during testing, so I know= it > > > > can happen.) > > > > > > > > > > > > > > > > > > > > > Thanks for any comments, rick > > > > > > ps: I have not, as yet, heard any comments w.r.t. whether or > > > > > > not this should go into FreeBSD15. (No rush on this one, > > > > > > but comments would be appreciated. > > > > > > > > > > I'd prefer the integration as soon as possible. > > > > A couple of problems here. > > > > 1 - You and Cedric are the only ones that have spoken up with suppo= rt for this. > > > > (Having said that, no one has spoken up against it.) > > > > 2 - Someone needs to do the "userspace" lifting at some point. > > > > I haven't yet asked, so I do not know if you feel commands lik= e "chmod(1)" > > > > need to be "named attribute aware"? (The fchmod(2) syscall wor= ks, but > > > > does the command line need to know how to do it? If yes, this = is work. > > > > Probably more than I've spent getting the syscalls to work.) > > > > 3 - A lot of the changes need to go into OpenZFS and I have no idea= what > > > > their position will be? (Most of the changes are in the os/fre= ebsd/zfs > > > > source subtree, which may make it easier?) > > > Oh, and another one... > > > Testing. I have yet to hear from anyone trying to test the code. I ob= viously > > > do some testing, but my resources are limited. > > > > How can we do this? Grab patch, apply patch, build FreeBSD, install > > new FreeBSD kernel? > Yes. For now, only the kernel needs to be replaced. (I haven't yet quite > figured out how to get the "zfs" command to set the new "named" value > for the xattr property, so the patch always sets it (ok for testing only)= . > > Basically, install a recent FreeBSD snapshot of 15. If you go onto > ftp.freebsd.org anonymous ftp, then cd into: > pub/FreeBSD/snapshots/ISO-IMAGES/15.0 > - You'll find a bunch of install images there. > If you are installing on 64bit Intel (x86-64), you want one with "amd64= " > in the name. > The ones I use have "disc1.iso" in the name. These are full install > images that I burn onto a DVD. (I don't know what is convenient > for newer hardware, but I'm sure someone will help if you can't > figure out which one to use for the hardware/vm you are installing on.) > > Install it, including src. You'll need ZFS setup. This is covered in the > handbook or you can just install a ZFS root fs for testing. > > Once this system is up, grab the patches and apply them to /usr/src. > (If they don't apply cleanly, let me know and I can help. I am not tracki= ng > main/current and am using a Jan. snapshot.) > > Build/install a new kernel via (as root/su): > # cd /usr/src > # make buildkernel > # make installkernel > -> Reboot. > # cp /usr/src/sys/sys/fcntl.h /usr/include/sys Oh, and you have to set xattr to dir and not sa. # zfs set xattr=3Ddir - If you do not know what the file system is called, do: # zfs get xattr - and look for it under Name I am now less convinced that a new value for xattr is needed. I need to do more testing, but with xattr set to dir and not sa (shown as "on" for zfs get xattr), the attributes seem compatible and it is just the KAPI which changes. rick > > Now, you have to set up NFSv4. The basic steps are: > - Create a /etc/exports. For testing one file system, 2 lines are needed. > /filesystem -alldirs -maproot=3Droot > V4: / > (should be all you need for testing) > > Add the following lines to /etc/rc.conf: > nfsuserd_enable=3D"YES" > nfsuserd_flags=3D"-domain " > nfs_server_enable=3D"YES" > nfsv4_server_enable=3D"YES" > nfsv4_server_only=3D"YES" > - This should be sufficient for the NFSv4 server. > To use the NFSv4 client, add: > nfs_client_enable=3D"YES" > nfscbd_enable=3D"YES" > > To do local testing of ZFS, you don't need the NFSv4 setup. > Just cd into the ZFS file system and bash away at it. > > For both local testing and testing over NFSv4, you can start with > https://people.freebsd.org/~rmacklem/xattrtest.c > and work from there. > > > > > The biggest issue for me is building and installing a new kernel in an > > existing FreeBSD installation, or finding someone in-house who can do > > that. > > Howto or short blog post would be nice > > > > > > > > For example, the pynfs test suite does have some xattr testing in it. > > > However, I haven't used the pynfs test suite in a long time and am no= t > > > a Python guy. It would be nice if someone else fired it up and did th= is > > > testing. (If problems are found, I could probably track them down and > > > fix them.) > > > > > > rick > > > ps: In case you do not know, I am one guy who does this NFS stuff as > > > a spare time hobby. I am not paid any $$$ by anyone to do it. > > > > Well, if you want a (NFS) job at CERN let me know (on-site, not remote)= . > Thanks, but I am just shy of the big 70 and happily retired. > > rick > > > > > Lionel From nobody Thu Mar 27 00:17:28 2025 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 4ZNPP96C1wz5rQlY for ; Thu, 27 Mar 2025 00:17:33 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZNPP90x3zz3KlM for ; Thu, 27 Mar 2025 00:17:33 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=Ei1FxduG; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of grahamperrin@gmail.com designates 2a00:1450:4864:20::32f as permitted sender) smtp.mailfrom=grahamperrin@gmail.com Received: by mail-wm1-x32f.google.com with SMTP id 5b1f17b1804b1-43948f77f1aso3133715e9.0 for ; Wed, 26 Mar 2025 17:17:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1743034650; x=1743639450; darn=freebsd.org; h=content-transfer-encoding:in-reply-to:references:subject:to:from :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=hz2fIP2VFGGTFRlDGneeM9Qwy1bvIpAsUZRAjPE4Ldg=; b=Ei1FxduGuWAXvH3P5lHwCju+mbCy777EhNzRFIzIzx+oB4Rd8in3SQuvpGbBU11itQ X2w05B6AIqTBVRdCKvxx3nGdBQfqPMU287LKjUU8afJ5CuLOzkG65Y+GLcnzJSJmzrBL JO9F8OxJFww5Kc/5ftSXpCBTfTPmeF64ZeTDPgE5ZgXa66Gnvz5VyeHGCy1CJCiobQJF XpzIRZti5TuoxIrQ7LKCyDAdNorNTUMwvJ8UUojaN2iskcEoQPJr28ugzKq4F6GyrbXk GvMNV+o5sfdZVSST/tgtI6dsjd9o4fSRn2QmxYCXZNEf3IIKRp/T3VWqC64qzGt7YTjG 3xkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743034650; x=1743639450; h=content-transfer-encoding:in-reply-to:references:subject:to:from :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=hz2fIP2VFGGTFRlDGneeM9Qwy1bvIpAsUZRAjPE4Ldg=; b=B1WeTEHYoXvymzLXw/IQ/UQZKQvJPls0F8zVFwND08MQI/pW+2aE0r+9zyiDq5eCEo vTU89Y9YMriyRoqUSbsMxIR04vfubgJUen8Ht24+4I+5rgvpGxTtNVnoI5bHw+zeDMef KZxzLciewiYAnHxvA8lFaWx+VYG/aiUiObG1q0vMWJCh5kFHNnjw4KP+gbFs9pCe6N36 /XoflZtoBaLTRO9ciXGO+bEVkTNGVacdJxVR+sSrHVkjGqGYceJcB7XDgN07/h6eFOGi ebmAJBTpV3Xr38HCgR5g7yQbGMIEQREuWbsd1pxQY/6AVZyCO+uRtMyBmLs7jnsyHExK qCmQ== X-Gm-Message-State: AOJu0YzdQe2nTRXJZffqD91kzSFP2QP9fg/c5mAc4ivFIPJ8DwZxiXHl KDYo2PCasnD9lxlUjaKeBHkwAG66e1aivQptYZJ6jDjo/iUDJqGJNa38vA== X-Gm-Gg: ASbGncu6Of4mhYUSYmRIlxFxBaekbhfKrtx3p9xuH3HrshE4wGN/9s3Ef+VQLRebQEc 88aly9ApXzAasSmN34t1VTGWNF9er4pRdHAJfrfoym5VMc2dntb0isjeFSTUWKsURbsbcQCmkSR qrOPj74VCBcqIgNTZUGwd4jBnJgg0O2SgKjxHGWfimW1gANc4cIYhvnN+1cHidcd7ttfJvohDLf ZV8e0FF6nMJxV+TbRM6TfyjUEP+Yjglj9LOnEDogNReqcdrBnctYXOqBNvN/5CrjyEC/m76rkas Gl//99uGGvrM0zLtrmn1MeWZfeck+SwXa8J46vATIOa4KWF4Wq0kVwmHkt+gkK/B2oHAkmFeYxs b5A== X-Google-Smtp-Source: AGHT+IGU2U9u4+7fPPD1HlIAyDR5N8I45U0xH1TBHsqvPScXdEDpxxWzkydu9bjPySVz0o8m4UoSXw== X-Received: by 2002:a05:600c:3d8c:b0:43d:649:4e50 with SMTP id 5b1f17b1804b1-43d871ac058mr4769755e9.13.1743034649692; Wed, 26 Mar 2025 17:17:29 -0700 (PDT) Received: from [192.168.1.10] (host-78-150-77-46.as13285.net. [78.150.77.46]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-43d82efe9b4sm18425255e9.20.2025.03.26.17.17.29 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 26 Mar 2025 17:17:29 -0700 (PDT) Message-ID: <88ff7cdd-60ac-41de-9b51-6b4864c31ef6@gmail.com> Date: Thu, 27 Mar 2025 00:17:28 +0000 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 Thunderbird From: grahamperrin@gmail.com To: freebsd-current@freebsd.org Subject: Re: suspend/resume broken on Thinkpad x230 References: <30322e00-271d-41f7-aa76-48e5074018b2@FreeBSD.org> In-Reply-To: <30322e00-271d-41f7-aa76-48e5074018b2@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Result: default: False [-1.67 / 15.00]; NEURAL_HAM_SHORT(-1.00)[-0.998]; NEURAL_SPAM_LONG(0.84)[0.838]; NEURAL_HAM_MEDIUM(-0.51)[-0.514]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; RCPT_COUNT_ONE(0.00)[1]; DKIM_TRACE(0.00)[gmail.com:+]; RCVD_COUNT_TWO(0.00)[2]; FREEFALL_USER(0.00)[grahamperrin]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::32f:from]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; FROM_NO_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-Rspamd-Queue-Id: 4ZNPP90x3zz3KlM X-Spamd-Bar: - Which driver? pkg iinfo drm On 26/03/2025 14:01, Renato Botelho wrote: > … Another user reported same problem on his thinkpad x270 What are the graphics cards in your machine, and the other user's? From nobody Thu Mar 27 02:28:32 2025 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 4ZNSJY5BQJz5rZlJ; Thu, 27 Mar 2025 02:28:45 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZNSJY13Qlz3RRC; Thu, 27 Mar 2025 02:28:45 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x52d.google.com with SMTP id 4fb4d7f45d1cf-5e60cfef9cfso701369a12.2; Wed, 26 Mar 2025 19:28:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1743042523; x=1743647323; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=OGwrNVh/WZTTtw7uAqgZK0CpG9xq3xfhc8jxsCdvx0E=; b=cNi8ZtYXHCtjSLtWZo9CHykpbLBkx5pkGvfGsc58IKZafwfJPESz91cezthDQ8b9DS c8Xs7EwrLeXcMJJi1lNG9Rjcl6zCyHoR7Kp+jfV9ylKhSSRC/F9xbRATAZeK4mxlMYDP DsKjNVtmkIkmy+zZhnNmb6w4566zzicgfloqggpq3rHvhs9KAOFELZLJTDadIyKAgeks 6kyHSU8YFU9FjlQ6KRWzFDXxSiB4fWZxyyAMHMyqV1w6fZy+4hzrsHQLBX0tA/xbVFiS qJIHXS5OV8Sc6iaOc4wiBax48lOVSq6pMC9pyUUCKG8qY36Gm+jh2++ia0m84xrg/TP2 ZNeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743042523; x=1743647323; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=OGwrNVh/WZTTtw7uAqgZK0CpG9xq3xfhc8jxsCdvx0E=; b=CyglkdWDSb3kpB40X9UmG8r1mQvb1szpp+8YLTnAtJSOUSZFq3ZPEmn2fyQBA9m8jm t1iA+ls9xMS1XXIJHg9C+WiiJtaqWsQ7pn6g7gexn1rrZWsd97yYIZd/qk/sSZtfYifW 9yVu1YwEWscojqWtVe665MzI1tR1ZkaNxspgSAkHy2h7wQzMrsYJEsF0joxvHfcn1HJi qwG/fs8lQL+JxI3lJQN5fvF4s2/ydncVDTXJmOgzv7nBIZaJzGW37q9Nu8RkL8JVcwqB fXvLUDUgiTe4rFllyWNjzftnjx8PWgI+YlFGaU8osy2tQ9+aKxG3j1UbShoPB/Odvs+k 2amQ== X-Forwarded-Encrypted: i=1; AJvYcCUePxwXGeQVWQ5LZ3KMoSZSRo5NNY3W7lPMY8qNSTxwtaZTLmb1ctJG7gTovd/pAXkdstXd@freebsd.org, AJvYcCUgJXh/7O9FbBZrLoPvrreAOLq0g18z5cseuID1da7fOU5UPYoU0tB1TOoZ6sIVUw7KopQpknuueN6aWoqS4bhq@freebsd.org, AJvYcCV2N4nb1j964WC1O6YpnWSe7EurvHzuNScDlf/VFRTTpifUs9tqp0SWtNb9EZHYV7u+4U6j6anbVRlvsRY=@freebsd.org X-Gm-Message-State: AOJu0YwTdE/fniZ/4ZXbq6RiRLQ11KArGtH78uYt137/8KvPnXKXi8bq UfGGiu+PxcOjncHKJ9A8Z94CnJVhHB1vlsHI9Z5DrS3CM7FqsvMjPsk5LGqxJIL4Bp/enpPxFuZ G9umMneWdCTylXl7iqH2uEns7CA== X-Gm-Gg: ASbGncuQW8eE9uZvx0FTC9XyuuXTjR6XJ//Nf9hRuGYW0L6EmGp6CSaKUub6jsYxPhi B+uL+7JYnGnv8zRC4+ei8q9AStGdOXUE5IpuiD6NePkdqfbJHLt+yEaWFw9FvGZ8krbUpXue+Oa CP+1119dtIs0RWKmrV17JD8UG+EOUgNRve1g8VXxlXkdnwEmZGzUFsLHl6bA== X-Google-Smtp-Source: AGHT+IGh+jwsKkoTC7Jp9KQTmGLXlmHgEYcWxlRtqOWkt1Nuzfdt7SDtAEWE6AOdIamX7fG6p1X/lKtoOuto3dP/KwU= X-Received: by 2002:a05:6402:350c:b0:5e4:9348:72c3 with SMTP id 4fb4d7f45d1cf-5ed8e27b242mr1895825a12.10.1743042522877; Wed, 26 Mar 2025 19:28:42 -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: In-Reply-To: From: Rick Macklem Date: Wed, 26 Mar 2025 19:28:32 -0700 X-Gm-Features: AQ5f1JrcUWjR-JU3Jt2RYk_XN-QAhpqzkO8QRl65AMNHWFYKKsMKEXUnBsMLaBY Message-ID: Subject: Re: RFC: Solaris style extended attributes for FreeBSD To: Andrew Walker Cc: Lionel Cons , Konstantin Belousov , freebsd-arch@freebsd.org, FreeBSD CURRENT , Cedric Blancher Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_RCPT(0.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Queue-Id: 4ZNSJY13Qlz3RRC X-Spamd-Bar: ---- On Wed, Mar 26, 2025 at 5:36=E2=80=AFPM Andrew Walker wrote: > > On Wed, Mar 26, 2025 at 5:05=E2=80=AFPM Rick Macklem wrote: > > I am now less convinced that a new value for xattr is needed. > > I need to do more testing, but with xattr set to dir and not sa > > (shown as "on" for zfs get xattr), the attributes seem compatible > > and it is just the KAPI which changes. > > > > rick > > Rick, is it OK to serve the same information as an xattr and as a > named attribute over NFS? Good question. I don't have the answer. It seems that it "will work", so so long as the "system attrnamespace" attributes cannot be accessed/crea= ted on the named attribute side, I don't se an obvious problem (see below). > I'm thinking of how this will interplay with xattrs via RFC8276 since > they all occupy the same namespace. The only issue I am aware of related to RFC8276 is size of the attribute data. Right now, you can create a pretty large (as in data size in bytes) attribute using ZFS and the setextattr API, which will not be accessible via the RFC8276 operations. (They are limited to a single RPC to get the entire attribute's data and the RPC size is typically limited to just over 1Mbyte.) --> They can fail now. With named attribute support, a NFSv4 client will be able to read all the data. > > Being able to fchmod named attributes may also present some unexpected > permissions issues with > users trying to access them via xattr interfaces. Yes, access is something I am just starting to test. Sofar I see the owner = of the file (and therefore also the attribute) can access the file no matter w= hat the attribute file's mode is. Access permissions is where I'll be spending time doing testing for the next while. Will it be identical to the FreeBSD extended attribute model? - I suppose we can make it so, but it probably is not so at this time. I think it could be coded such that the mode of the attribute file is ignored and access to the directory via the mode/uid/gid/acl of the associated object is all that is checked. --> This would make access permissions the same as the FreeBSD extended attribute model but might make it less Solaris compatible? (As Alexander mentioned, it would be nice to know what Windows and Mac OSX does w.r.t. this, too.) rick > > Andrew From nobody Thu Mar 27 09:13:10 2025 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 4ZNdHM37WSz5s3JF for ; Thu, 27 Mar 2025 09:13:19 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZNdHL64pZz42hp; Thu, 27 Mar 2025 09:13:18 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; none Received: from kalamity.joker.local (124-18-43-114.area1c.commufa.jp [124.18.43.114]) (authenticated bits=0) by www121.sakura.ne.jp (8.17.1/8.17.1/[SAKURA-WEB]/20201212) with ESMTPA id 52R9DAaD070606; Thu, 27 Mar 2025 18:13:13 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dec.sakura.ne.jp; s=s2405; t=1743066793; bh=keU97qpBGeQa7r8YErc6pX0RASpG7UT9q7Ws0ziyRHY=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=EpwwzPPe9/8ehrTnTEAnckmD/HXtPKkpGzPrTaQQySDNIIDH+m/rqGz/SiIgl8LIa jxiVSR71MYJdu1oBRe4xumcM11h3/Gd6M2i1kWfBvMFbNMHti6Ejxf9M9l+nJUTt1s XMJNEZ4c9A5HKMAhSD6i7kaM7QuDsNbkXzaAqMJs= Date: Thu, 27 Mar 2025 18:13:10 +0900 From: Tomoaki AOKI To: Olivier Certner Cc: freebsd-current@freebsd.org Subject: Re: March 2025 stabilization week Message-Id: <20250327181310.709a04c547e5ffb02b0fb508@dec.sakura.ne.jp> In-Reply-To: <24245312.gYbqZ1YImA@ravel> References: <6881633.Qb2xPn7ZBO@ravel> <20250326213914.6d9b9e33e3f19822c5f98116@dec.sakura.ne.jp> <24245312.gYbqZ1YImA@ravel> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.2) 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-Transfer-Encoding: 7bit X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP] X-Rspamd-Queue-Id: 4ZNdHL64pZz42hp X-Spamd-Bar: ---- On Wed, 26 Mar 2025 19:02:35 +0100 Olivier Certner wrote: > Hi, > > Commit 2619c5ccfe1f7889f0241916bd17d06340142b05 you mentioned is not a functional prerequisite (but it may prevent applying the patch straight away). > > Please find attached the straightforward MFC to stable/14 I've been using. > > Thanks and regards. > > -- > Olivier Certner Thanks! I couldn't have determined it was really a prerequisite or not. Your patch applied cleanly, built fine and at least currently no harm to graphics/nvidia-drm-61-kmod on stable/14, amd64 at commit b0d6aa07c19370fd9c936f4ed28fe391b530bb9f. Regards. -- Tomoaki AOKI From nobody Thu Mar 27 12:50:32 2025 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 4ZNk6C2Wqdz5rKP3 for ; Thu, 27 Mar 2025 12:50:43 +0000 (UTC) (envelope-from cglogic@protonmail.com) Received: from mail-40138.protonmail.ch (mail-40138.protonmail.ch [185.70.40.138]) (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 "protonmail.com", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZNk693QTlz3hnF for ; Thu, 27 Mar 2025 12:50:41 +0000 (UTC) (envelope-from cglogic@protonmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=protonmail.com header.s=protonmail3 header.b=McrUH3Jo; dmarc=pass (policy=quarantine) header.from=protonmail.com; spf=pass (mx1.freebsd.org: domain of cglogic@protonmail.com designates 185.70.40.138 as permitted sender) smtp.mailfrom=cglogic@protonmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1743079837; x=1743339037; bh=Frh5QZ3LoO1MdSuXCjzxToMMcYZVLnkKebIr4mOctCI=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=McrUH3JopcyjL3dJs3ktbO1QHExd40EM6/46NufHEgF/bHVWnTEwicrJYvdUgJWM7 uII6twsUkfE6DK76b4UUvX95KfF9xHTFi9we79ALsj841mtEDfcmav239FxYbD6+he K4TNHIpdSt0p9yyU20DppJfBmZ/pK9FNYxLdFkmjE370N7t21ZRyTfSWhDKYptRSzl mCCOf+5eGardpakHeOmZIQPXRAhKdgS5T+1+h/whNBbynetnjCnNL10wMxHrgGoINu YNfon8+m39TdAqlwPzLN/GpyZG7ukgCquXBiDg7nQbZehE/WcsXr39x0T5dWJ7pOIH +PopMCebii3pA== Date: Thu, 27 Mar 2025 12:50:32 +0000 To: Warner Losh From: cglogic Cc: Minsoo Choo , FreeBSD CURRENT Subject: Re: Long time outdated jemalloc Message-ID: In-Reply-To: References: <4L_wVuJx1yIMEv85fQKvrJp8QiaTK4Fe_TvymIq0vcdwdHqa06Ys4lqAM8aHb-kefxPiIZW7kxT8qI7hmv4bLngKUlzIWfBVzDcaz4VRIPY=@proton.me> Feedback-ID: 25313618:user:proton X-Pm-Message-ID: 6ee4fb72c30079b881b6ae153242938bea6d3a15 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: multipart/alternative; boundary="b1=_JWexQ6bpLKudsw2VBuqTCOLcF6jLLhngbknHlLjCiU" X-Spamd-Result: default: False [-0.91 / 15.00]; RBL_SENDERSCORE_REPUT_9(-1.00)[185.70.40.138:from]; NEURAL_SPAM_LONG(1.00)[0.999]; NEURAL_HAM_SHORT(-0.99)[-0.995]; NEURAL_SPAM_MEDIUM(0.99)[0.988]; DMARC_POLICY_ALLOW(-0.50)[protonmail.com,quarantine]; R_SPF_ALLOW(-0.20)[+ip4:185.70.40.0/24]; R_DKIM_ALLOW(-0.20)[protonmail.com:s=protonmail3]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; MIME_BASE64_TEXT(0.10)[]; TO_DN_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; ARC_NA(0.00)[]; FREEMAIL_FROM(0.00)[protonmail.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[protonmail.com]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; DKIM_TRACE(0.00)[protonmail.com:+]; RCVD_IN_DNSWL_NONE(0.00)[185.70.40.138:from]; RCVD_COUNT_ZERO(0.00)[0]; MID_RHS_MATCH_FROM(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; RWL_MAILSPIKE_POSSIBLE(0.00)[185.70.40.138:from]; ASN(0.00)[asn:62371, ipnet:185.70.40.0/24, country:CH]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MISSING_XM_UA(0.00)[]; FROM_HAS_DN(0.00)[] X-Rspamd-Queue-Id: 4ZNk693QTlz3hnF X-Spamd-Bar: / --b1=_JWexQ6bpLKudsw2VBuqTCOLcF6jLLhngbknHlLjCiU Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SGkgV2FybmVyLAoKU2V2ZXJhbCB1c2VycyBoYXZlIGJlZW4gcnVubmluZyB0aGVpciBzeXN0ZW1z IHdpdGggdGhlIHVwZGF0ZWQgamVtYWxsb2MgZm9yIGEgd2hpbGUgbm93LiBJJ3ZlIGJlZW4gcnVu bmluZyBteSBzeXN0ZW1zLCBhIGR1YWwtc29ja2V0IE5VTUEgd29ya3N0YXRpb24gYW5kIGEgbGFw dG9wIChib3RoIHg4Nl82NCksIGZvciBvdmVyIGEgeWVhciB3aXRob3V0IGlzc3Vlcy4KCk1heSBJ IHN1Z2dlc3QgaW1wb3J0aW5nIHRoZSB1cGRhdGVkIGplbWFsbG9jIGludG8gMTUtQ1VSUkVOVCBm b3Igd2lkZXIgdGVzdGluZz8gSXQncyBiZXR0ZXIgdG8gaGF2ZSBpdCBpbiB0aGUgdHJlZSBmb3Ig YSBsb25nZXIgcGVyaW9kIG9mIHRpbWUgYmVmb3JlIHRoZSAxNS4wIHJlbGVhc2UuClNvcnJ5IGZv ciB0aGUgbm9pc2UgYW5kIHRoYW5rcy4KCk9uIFN1bmRheSwgRGVjZW1iZXIgOHRoLCAyMDI0IGF0 IDc6NDEgUE0sIFdhcm5lciBMb3NoIDxpbXBAYnNkaW1wLmNvbT4gd3JvdGU6Cgo+IEdyZWF0ISBJ J2xsIHRha2UgYSBsb29rIGF0IHRoYXQsIGFzIHdlbGwgYXMgZG8gdGhlIG1lcmdlIHRoZSB0eXBp Y2FsIHdheSAod2hpY2ggb25seSB0YWtlcyBhIGZldyBtaW51dGVzIG5vdyB0aGF0IEkndmUgYm9v dHN0cmFwcGVkIHRoaW5ncykuIEknbGwgY29tcGFyZSB0aGUgdHdvIHRvIHNlZSB3aGF0IGRpZmZz IHRoZXJlIG1pZ2h0IGJlICh0byBhY3QgYXMgYSBjcm9zcyBjaGVjayBmb3IgYm90aCBtZXRob2Rz KS4gSSdsbCB0aGVuIGJ1aWxkIGEgY29weSBvZiB0aGUgTmV0ZmxpeCBmaXJtd2FyZSB3aXRoIHRo ZSBjaGFuZ2UgYW5kIHB1dCBpdCBvbiBhIGNvdXBsZSBtYWNoaW5lcyBhbmQgc2VlIGlmIHRoZXkg Y2FuIGhhbmRsZSB0aGUgbG9hZCBhbmQgaWYgdGhlcmUgYXJlIGFueSBwZXJmb3JtYW5jZSByZWdy ZXNzaW9ucy4gSSBkb24ndCBleHBlY3QgYW55LCBzaW5jZSBtYWxsb2MgdHlwaWNhbGx5IGRvZXNu J3QgYXBwZWFyIGluIHRoZSBmbGFtZSBncmFwaHMgYXMgInZpc2libGUiLCBidXQgeW91IG5ldmVy IGtub3cuCj4KPiBTbywgb25jZSB0aGF0J3MgZG9uZSwgYW5kIEkgZXhwZWN0IGl0IHRvIGJlIGRv bmUgdGhpcyB3ZWVrLCBJJ2xsIHB1c2ggaXQgaW50byBtYWluIHdpdGggYm90aCB0aGUgcHJvcGVy IHZlbmRvciBicmFuY2ggbWVyZ2UgY29tbWl0cyBhcyB3ZWxsIGFzIGFuIGFja25vd2xlZGdlbWVu dCBmb3IgdGhpcyBwdWxsIHJlcXVlc3QgYW5kIHlvdXIgd29yayB0byBtb3ZlIGl0IGZvcndhcmQg KEknbSBqdXN0IHZlcmlmeWluZyB0aGUgdHlwaWNhbCBwcm9jZXNzIHdpbGwgcHJvZHVjZSB0aGUg c2FtZSByZXN1bHRzIGFuZCB0aGUgdHlwaWNhbCBwcm9jZXNzIGRvZXNuJ3QgdGFrZSBhIGxvbmcg dGltZSwgZXRjKS4KPgo+IFdhcm5lcgo+Cj4gT24gU3VuLCBEZWMgOCwgMjAyNCBhdCA5OjAz4oCv QU0gTWluc29vIENob28gPG1pbnNvb2Nob28wMTIyQHByb3Rvbi5tZT4gd3JvdGU6Cj4KPj4gSSBy ZXNvbHZlZCBtZXJnZSBjb25mbGljdCBieSByZWJhc2luZyBtYWluLiBXaGF0J3MgbmV4dD8KPj4K Pj4gaHR0cHM6Ly9naXRodWIuY29tL2ZyZWVic2QvZnJlZWJzZC1zcmMvcHVsbC8xMzM3Cj4+IE9u IFN1bmRheSwgRGVjZW1iZXIgMXN0LCAyMDI0IGF0IDI6MDUgQU0sIFdhcm5lciBMb3NoIDxpbXBA YnNkaW1wLmNvbT4gd3JvdGU6Cj4+Cj4+PiAoc29ycnkgdG8gZm9sbG93IHVwIHRvIG15IG93biBl bWFpbCBhbmQgdG9wcG9zdGluZykKPj4+Cj4+PiBJIGdvdCB0aGUgdmVuZG9yIGJyYW5jaCBib290 c3RyYXBwZWQ6IEkgY3JlYXRlZCB2ZW5kb3IvamVtYWxsb2MgYW5kIHRhZ2dlZCB2ZW5kb3IvamVt YWxsb2MvNS4yLjEsCj4+PiBhbmQgY3JlYXRlZCBhIG1lcmdlIGNvbW1pdCBmcm9tIHRoYXQgYnJh bmNoIHRvIG1haW4uIEkgaGFkIHRvIHR3ZWFrIHRoZQo+Pj4gRlJFRUJTRC1YbGlzdCBhIGxpdHRs ZS5JJ3ZlIG5vdCB1cGRhdGVkIHRoZSBvdGhlciB0d28gRlJFRUJTRC0qIGZpbGVzLCBidXQgdGhl IHN0ZXBzIHdlcmUKPj4+IGRvY3VtZW50ZWQgaW4gdGhlIGNvbW1pdCBtZXNzYWdlcyAodGhlIHZl bmRvciBicmFuY2ggb25lIGlzIGVzcGVjaWFsbHkgbG9uZyBhbmQKPj4+IGxpa2VseSBzaG91bGQg bWlncmF0ZSBpbnRvIHRoZSBkZXZlbG9wZXIgaGFuZGJvb2spLiBGUkVFQlNELXVwZGF0ZSBpcyBi YXNpY2FsbHkKPj4+IGEgc2hlbGwgc2NyaXB0IHRvIGRvIHRoZSBzYW1lIHRoaW5nIHRoYXQgZ2l0 IHN1YnRyZWUgbWVyZ2UgZG9lcywgdGhvdWdoIEknbSBzdXJlIHNvbWUKPj4+IHR3ZWFrcyBjb3Vs ZCBoZWxwIHRoZSBuZXh0IHRpbWUgKGlmIHRoZXJlIGlzIGEgbmV4dCB0aW1lLCBqZW1hbGxvYyB1 cHN0cmVhbSBzZWVtcyB0bwo+Pj4gaGF2ZSBzbG93ZWQgd2F5IGRvd24gb2YgbGF0ZSkuCj4+Pgo+ Pj4gTmV4dCB1cCxJJ2xsIGNyZWF0ZSA1LjMuMCBpbXBvcnQgb24gdGhlIHZlbmRvciBicmFuY2gs IGRvIHRoZSBtZXJnZSBhbmQgc3RhcnQgdGVzdGluZyAoaXQgd2lsbCBiZQo+Pj4gTWluc29vJ3Mg cHVsbCByZXF1ZXN0LCByZWJhc2VkLCB3aXRoIGFueSBjb25mbGljdHMgcmVzb2x2ZWQgYW5kIG1l cmdlIGNvbW1pdCByZWNvcmRlZCkuCj4+PiBCdXQgdGhhdCB3aWxsIGhhdmUgdG8gYmUgdG9tb3Jy b3cgb3IgbW9yZSBsaWtlbHkgZHVyaW5nIHRoZSB3b3JrIHdlZWsuIEknbSB0b28gdGlyZWQgdG9u aWdodAo+Pj4gdG8gZ2V0IGl0IHJpZ2h0IGF0IHRoZSBtb21lbnQuCj4+Pgo+Pj4gQW5kIGEgc3Bl Y2lhbCB0aGFua3MgdG8gZW1hc3RlIGZvciBnaXZpbmcgYnogdGhlIHJpZ2h0IHJlY2lwZSBmb3Ig ZG9pbmcgdGhlIHN1YnRyZWUgbWVyZ2UKPj4+IHcvbyBnaXQgc3VidHJlZSBmb3IgaGlzIHdvcmsg b24gdGhlIGxpbnV4IHdpZmkgZHJpdmVycyBpbiB0aGUgdHJlZS4KPj4+Cj4+PiBXYXJuZXIKPj4+ Cj4+PiBPbiBTYXQsIE5vdiAzMCwgMjAyNCBhdCA5OjM44oCvUE0gV2FybmVyIExvc2ggPGltcEBi c2RpbXAuY29tPiB3cm90ZToKPj4+Cj4+Pj4gWWVhLCBJIG5lZWQgdG8gZ2V0IGEgY29weSBvZiBq ZW1hbGxvYyA1LjMuMCBhbmQgNS4yLjEgdG8gdHJ5IHRvICdib290c3RyYXAnIHRoZSB2ZW5kb3Ig YnJhbmNoLgo+Pj4+IFRoZW4gSSBuZWVkIHRvIGJvb3RzdHJhcCBpdC4uLgo+Pj4+Cj4+Pj4gSSBq dXN0IGRpZCB0aGUgc2FtZSB3aXRoIGVkazIgKHdoaWNoIGhhZCBhIHZlbmRvciBicmFuY2gsIGJ1 dCBoYWRuJ3QgYmVlbiB1cGRhdGVkIHNpbmNlIHN2biB0aW1lcykuCj4+Pj4gSG93ZXZlciwgamVt YWxsb2MgZG9lc24ndCBoYXZlIGEgdmVuZG9yIGJyYW5jaCB5ZXQsIHNvIEknbGwgaGF2ZSB0byBj cmVhdGUgdGhhdCwgYnV0IEknbGwgc3RhcnQgd2l0aCB0aGUKPj4+PiBjdXJyZW50IHZlcnNpb24g cmF0aGVyIHRoYW4gZG9pbmcgZnVsbCBoaXN0b3J5Li4uIFNvIEknbGwgc3RhcnQgdGhlcmUuCj4+ Pj4gSSBhbHNvIGp1c3QgZGlkIGF3ayBhbmQgbHVhLCBzbyBvbmNlIEkgaGF2ZSB0aGluZ3MgYm9v dHN0cmFwcGVkLCBJJ2xsIGJlIGFibGUgdG8gYWRkIDUuMy4wIGFuZCB0aGVuIGxheWVyIE1pbnNv bydzIG9uCj4+Pj4gdG9wIG9mIHRoYXQgYW5kIHRoZW4gc3RhcnQgdGVzdGluZyBpdCBzb21laG93 Lgo+Pj4+Cj4+Pj4gTWFsbG9jIG1ha2VzIG1lIG5lcnZvdXMgdG8gdG91Y2gsIGhvbmVzdGx5LCBi dXQgSSdsbCBnaXZlIGl0IGEgZ28gYW5kIHRlc3QgYm9vdCBvbiBteSBzeXN0ZW0gYW5kCj4+Pj4g bWF5YmUgc2VlIGlmIHdlIGNhbiBzdXJ2aXZlIGEgd29ya2xvYWQgYXQgd29yayB3L28gcmVncmVz c2lvbnMuLi4gQnV0IEkgY2FuJ3QgZG8gYSBmdWxsIHRlc3Qgd2l0aCBsb3RzCj4+Pj4gb2YgbWFj aGluZXMgdW50aWwgYWZ0ZXIgdGhlIGZpcnN0IG9mIHRoZSB5ZWFyICh0aG91Z2ggSSBjYW4gZG8g YSBjb3VwbGUgZm9yIGEgZmV3IGRheXMgYmVmb3JlIHRoZW4pLgo+Pj4+Cj4+Pj4gU28gbXkgbmV4 dCBzdGVwIGlzIHRvIGJvb3RzdHJhcCB0aGUgdmVuZG9yIGJyYW5jaC4uLiBJJ2xsIGdpdmUgdGhh dCBhIHRyeSB0b25pZ2h0Lgo+Pj4+Cj4+Pj4gV2FybmVyCj4+Pj4KPj4+PiBPbiBTYXQsIE5vdiAz MCwgMjAyNCBhdCA4OjI24oCvUE0gTWluc29vIENob28gPG1pbnNvb2Nob28wMTIyQHByb3Rvbi5t ZT4gd3JvdGU6Cj4+Pj4KPj4+Pj4gSSBoYXZlIGFscmVhZHkgc3VibWl0dGVkIFBSIG9uIGdpdGh1 YiAoaHR0cHM6Ly9naXRodWIuY29tL2ZyZWVic2QvZnJlZWJzZC1zcmMvcHVsbC8xMzM3KSBhbmQg cGhhYnJpY2F0b3IgKGh0dHBzOi8vcmV2aWV3cy5mcmVlYnNkLm9yZy9ENDE0MjEpLiBJIGRvbid0 IGhhdmUgYWNjZXNzIChjb21taXQgYml0KSB0byBmcmVlYnNkIGdpdCByZXBvLCBzbyB0aGVyZSBp cyBub3RoaW5nIEkgY2FuIGRvIGF0IHRoaXMgcG9pbnQgc2luY2UgdmVuZG9yIGltcG9ydCBhbmQg bGFuZGluZyBwYXRjaGVzIHJlcXVpcmVzIGNvbW1pdCBiaXQuCj4+Pj4+IE9uIFNhdHVyZGF5LCBO b3ZlbWJlciAzMHRoLCAyMDI0IGF0IDE6NDIgUE0sIGNnbG9naWMgPGNnbG9naWNAcHJvdG9ubWFp bC5jb20+IHdyb3RlOgo+Pj4+Pgo+Pj4+Pj4gSSBzZWUsIGl0IGhhcHBlbnMuCj4+Pj4+PiBNYXli ZSBhbm90aGVyIGNvbW1pdHRlciB3aWxsIHZvbHVudGVlciB0byBkbyB0aGUgdXBkYXRlLgo+Pj4+ Pj4gSSBob3BlIGl0IHdpbGwgbWFrZSBpdHMgd2F5IGludG8gMTUuMCByZWxlYXNlLgo+Pj4+Pj4K Pj4+Pj4+IFRoYW5rcy4KPj4+Pj4+IE9uIEZyaWRheSwgTm92ZW1iZXIgMjl0aCwgMjAyNCBhdCA5 OjM4IFBNLCBXYXJuZXIgTG9zaCA8aW1wQGJzZGltcC5jb20+IHdyb3RlOgo+Pj4+Pj4KPj4+Pj4+ PiBJJ3ZlIGJlZW4gc3dhbXBlZC4gd2UgbmVlZCB0byBib290c3RyYXAgdGhlIHZlbmRvciBicmFu Y2gsIGFuZCB0aGUgd2F5IHByaW9yIHVwZGF0ZXMgd2VyZSBkb25lCj4+Pj4+Pj4gaXNuJ3Qgc28g Z3JlYXQuCj4+Pj4+Pj4KPj4+Pj4+PiBXYXJuZXIKPj4+Pj4+Pgo+Pj4+Pj4+IE9uIE1vbiwgTm92 IDI1LCAyMDI0IGF0IDI6MjHigK9BTSBjZ2xvZ2ljIDxjZ2xvZ2ljQHByb3Rvbm1haWwuY29tPiB3 cm90ZToKPj4+Pj4+Pgo+Pj4+Pj4+PiBIZWxsbyBndXlzLAo+Pj4+Pj4+Pgo+Pj4+Pj4+PiBIb3cg dGhlIHVwZGF0ZSBvZiBqZW1hbGxvYyBpcyBnb2luZz8gSXQncyBOb3ZlbWJlciBub3cuCj4+Pj4+ Pj4+Cj4+Pj4+Pj4+IFRoYW5rcy4KPj4+Pj4+Pj4gT24gTW9uZGF5LCBKdWx5IDIybmQsIDIwMjQg YXQgNzowMiBQTSwgTWluc29vIENob28gPG1pbnNvb2Nob28wMTIyQHByb3Rvbi5tZT4gd3JvdGU6 Cj4+Pj4+Pj4+Cj4+Pj4+Pj4+PiBGaXJzdCwgc29ycnkgZm9yIGxhdGUgcmVzcG9uc2UuCj4+Pj4+ Pj4+Pgo+Pj4+Pj4+Pj4gY2dsb2dpYywgdGhhbmsgeW91IGZvciBicmluZ2luZyB1cCB0aGlzIGlz c3VlIGFnYWluIHNpbmNlIEkgbmVhcmx5IGZvcmdvdCB0aGF0IHRoaXMgaXNzdWUgd2FzIHN0aWxs IG9wZW4uCj4+Pj4+Pj4+Pgo+Pj4+Pj4+Pj4gV2FybmVyLCBhcyBJIGNhbid0IGFjY2VzcyB0byBt eSBGcmVlQlNEIGluc3RhbmNlIHVudGlsIHRoZSBlbmQgb2YgQXVndXN0LCBidXQgSSBjYW4gc3Rp bGwgZWRpdCBhbmQgcHVzaCB0aGUgY29kZSB0aHJvdWdoIG15IEFybSBNYWMuIFRoaXMgbWVhbnMg dGhhdCBJIGNhbid0IHRlc3QgdGhlIHVwZGF0ZWQgY29kZSBvbiBteSBtYWNoaW5lLCBidXQgSSBj YW4gam9pbiB0aGUgcmV2aWV3IHByb2Nlc3MgYW5kIGxpc3RlbiB0byBjaGFuZ2UgcHJvcG9zYWxz Lgo+Pj4+Pj4+Pj4KPj4+Pj4+Pj4+IEknbGwgb3BlbiBhIEdpdGh1YiBQUiBpbiBhIGZldyBob3Vy cy4gKFRoZSBwaGFicmljYXRvciByZXZpZXcgd2lsbCBzdGF5IG9wZW5lZCBqdXN0IGluIGNhc2Up Cj4+Pj4+Pj4+PiBPbiBNb25kYXksIEp1bHkgMjJuZCwgMjAyNCBhdCA1OjA4IEFNLCBXYXJuZXIg TG9zaCA8aW1wQGJzZGltcC5jb20+IHdyb3RlOgo+Pj4+Pj4+Pj4KPj4+Pj4+Pj4+PiBPbiBTdW4s IEp1bCAyMSwgMjAyNCBhdCAyOjAz4oCvUE0gY2dsb2dpYyA8Y2dsb2dpY0Bwcm90b25tYWlsLmNv bT4gd3JvdGU6Cj4+Pj4+Pj4+Pj4KPj4+Pj4+Pj4+Pj4gT24gU3VuZGF5LCBKdWx5IDIxc3QsIDIw MjQgYXQgNjo1NCBBTSwgV2FybmVyIExvc2ggPGltcEBic2RpbXAuY29tPiB3cm90ZToKPj4+Pj4+ Pj4+Pj4KPj4+Pj4+Pj4+Pj4+IE9uIFNhdCwgSnVsIDIwLCAyMDI0IGF0IDE6NTnigK9BTSBjZ2xv Z2ljIDxjZ2xvZ2ljQHByb3Rvbm1haWwuY29tPiB3cm90ZToKPj4+Pj4+Pj4+Pj4+Cj4+Pj4+Pj4+ Pj4+Pj4gSGVsbG8gRnJlZUJTRCBjb21tdW5pdHksCj4+Pj4+Pj4+Pj4+Pj4KPj4+Pj4+Pj4+Pj4+ PiBBZnRlciBKYXNvbiBFdmFucyBzdGVwcGVkIGFzaWRlIGZyb20gbWFpbnRhaW5pbmcgamVtYWxs b2MgaW4gRnJlZUJTRCwgaXQncyBub3QgdXBkYXRpbmcgaW4gdGltZSBhbnltb3JlLgo+Pj4+Pj4+ Pj4+Pj4+IFZlcnNpb24gNS4zLjAgd2FzIHJlbGVhc2VkIE1heSA2LCAyMDIyIGFuZCBGcmVlQlNE IHN0aWxsIG5vdCBpbXBvcnRlZCBpdCBpbnRvIHRoZSB0cmVlLgo+Pj4+Pj4+Pj4+Pj4+Cj4+Pj4+ Pj4+Pj4+Pj4gVGhlcmUgaXMgYSBwZW5kaW5nIHJldmlldyBodHRwczovL3Jldmlld3MuZnJlZWJz ZC5vcmcvRDQxNDIxIGZyb20gQXVnIDExLCAyMDIzLgo+Pj4+Pj4+Pj4+Pj4+IEknbSBzdWNjZXNz ZnVsbHkgcnVubmluZyBGcmVlQlNEL2FtZDY0IHN5c3RlbSB3aXRoIEQ0MTQyMSBhcHBsaWVkIGZv ciA4IG1vbnRocywgYXMgd2VsbCBhcyBtYW55IG90aGVyIHBlb3BsZS4KPj4+Pj4+Pj4+Pj4+Pgo+ Pj4+Pj4+Pj4+Pj4+IENhbiBpdCBiZSByZXZpZXdlZCBhbmQgY29tbWl0dGVkIHRvIENVUlJFTlQ/ Cj4+Pj4+Pj4+Pj4+Pj4gT3IsIGlmIHRoZXJlIGlzIG5vIGNvbW1pdHRlcnMgd2lsbGluZyB0byBk byBpdCwgY2FuIGNvbW1pdCBiaXQgYmUgZ2l2ZW4gdG8gc3VibWl0dGVyIG9yIGFub3RoZXIgcGVy c29uIHdpbGxpbmcgdG8gZG8gdGhpcz8KPj4+Pj4+Pj4+Pj4+Pgo+Pj4+Pj4+Pj4+Pj4+IEl0J3Mg dmVyeSBkaXNhcHBvaW50aW5nIHdoZW4gdXNlcnMgc3BlbmQgdGhlaXIgdGltZSB0byBmaWxsIHN1 Y2ggZ2FwcyBhbmQgdGhlaXIgZWZmb3J0cyBqdXN0IGlnbm9yZWQgYnkgdGhlIGRldmVsb3BlcnMu Cj4+Pj4+Pj4+Pj4+Pj4KPj4+Pj4+Pj4+Pj4+PiBFdmVyeSB5ZWFyIEZyZWVCU0QgQ29tbXVuaXR5 IFN1cnZleSBhc2tpbmcgYWJvdXQgdXNlciBleHBlcmllbmNlIGluIGNvbnRyaWJ1dGluZyB0byBG cmVlQlNELgo+Pj4+Pj4+Pj4+Pj4+Cj4+Pj4+Pj4+Pj4+Pj4gSGVyZSB5b3UgY2FuIHNlZSBhbiBl eGFtcGxlIG9mIHN1Y2ggY29udHJpYnV0aW5nLgo+Pj4+Pj4+Pj4+Pj4KPj4+Pj4+Pj4+Pj4+IEZp cnN0LCB0aGFuayB5b3UgZm9yIGJlaW5nIHBlcnNpc3RlbnQgYW5kIGNvbnRpbnVpbmcgdG8gYnJp bmcgaXQgdXAuIEl0J3MgaW1wb3J0YW50IHRvIGRvIHRoYXQgdG8gbWFrZSBzdXJlIHRoaXMgKGFu ZCB5b3VyIG1hbnkgb3RoZXIpIGNvbnRyaWJ1dGlvbiBkb2Vzbid0IGZhbGwgb24gdGhlIGZsb29y Lgo+Pj4+Pj4+Pj4+Pj4KPj4+Pj4+Pj4+Pj4+IEFuZCB0byBiZSBmYWlyLCB3ZSdyZSBvbmx5IDMg bW9udGhzIHNpbmNlIHRoZSBsYXN0IHVwZGF0ZS4gU3RpbGwsIHF1aXRlIGEgYml0IGxvbmdlciB0 aGFuIHlvdSBzaG91bGQgaGF2ZSB0byB3YWl0LCBidXQgbm90IG5lYXJseSB0aGUgeWVhciB0aGUg b3JpZ2luYWwgZGF0ZSBzdWdnZXN0cy4KPj4+Pj4+Pj4+Pj4+Cj4+Pj4+Pj4+Pj4+PiBBbmQgdGhp cyBpcyBhIHBlcmZlY3Qgc3Rvcm0gb2YgImhvdyB0aGUgcHJvamVjdCBpcyBiYWQgYXQgYWNjZXB0 aW5nIGNvbnRyaWJ1dGlvbnMiOgo+Pj4+Pj4+Pj4+Pj4gKDEpIFRoZSBvcmlnaW5hbCBzdWJtaXNz aW9uIHdhcyBjbG9zZSB0byB0aGUgMTQgYnJhbmNoIGNyZWF0aW9uIHRpbWUuIFRoaXMgbWVhbnQg dGhhdCB3ZSB3ZXJlbid0IHdlbGwgcHJlcGFyZWQgdG8gbG9vayBhdCBpdCBzaW5jZSBpdCBpcyBz dWNoIGFuIGludmFzaXZlIGNoYW5nZSAoYXQgbGVhc3Qgb24gaXRzIHN1cmZhY2UpLiBJdCBhbHNv IHNsb3dlZCB0aGUgaW5pdGlhbCByZXNwb25zZS4uLgo+Pj4+Pj4+Pj4+Pj4gKDIpIFRoZXJlIHdh cyBhIG51bWJlciBvZiBiYWNrIGFuZCBmb3J0aCByZXF1ZXN0cyBmb3IgY2hhbmdlcywgd2hpY2gg dG9vayB0aW1lIHRvIHNvcnQgb3V0Li4uCj4+Pj4+Pj4+Pj4+PiAoMykgVGhlIHNpemUgb2YgdGhp cyBpcyBodWdlLCB3ZWxsIGJleW9uZCB0aGUgY2FwYWNpdHkgb2YgUGhhYnJpY2F0b3IgdG8gcmV2 aWV3IGFjY3VyYXRlbHkuLi4KPj4+Pj4+Pj4+Pj4+ICg0KSBJdCdzIGEgdmVuZG9yIGltcG9ydC4g VGhhdCBtZWFucyB3ZSBjYW4ndCBqdXN0IGRyb3AgdGhlIFBoYWJyaWNhdG9yIHJldmlldyBpbnRv IHRoZSB0cmVlLi4uCj4+Pj4+Pj4+Pj4+PiAoNSkgSXQncyBwaGFicmljYXRvcjogdGhpcyBpcyBh IGdyZWF0IHRvb2wgZm9yIGRldmVsb3BlcnMsIGJ1dCB3ZSBoYXZlIGEgdGVycmlibGUgdHJhY2sg cmVjb3JkIG9mIHVzaW5nIGl0IGZvciBpbnRha2UgZnJvbSBuZXcgY29udHJpYnV0b3JzLiBXZSBk b24ndCBoYXZlIGFueSBvdmVyc2lnaHQgYXQgYWxsIG92ZXIgdGhpcyB0b29sLCBhdCB0aGVyZSdz IGF0IGJlc3QgdGVwaWQgYW5kIGx1a2Ugd2FybSBhdHRlbXB0cyB0byBsb29rIGZvciBkcm9wIGJh bGxzLgo+Pj4+Pj4+Pj4+Pj4KPj4+Pj4+Pj4+Pj4+IEFsbCBvZiB0aGVzZSB0aGluZ3MgYXJlIGEg dGVycmlibGUgZXhwZXJpZW5jZS4gSSBjYW4gb25seSBhcG9sb2dpemUuIFRoZXNlIGRheXMsIHdl IG1pZ2h0IHN0ZWVyIHRoaXMgdG93YXJkcyBnaXRodWIsIGJ1dCB0aGUgJ3ZlbmRvciBpbXBvcnQn IG1lYW5zIHlvdSByZWFsbHkgbmVlZCBzb21lb25lIG9uIHRoZSBpbnNpZGUsIG9yIHlvdSBuZWVk IHRvIGJlIG9uIHRoZSBpbnNpZGUgdG8gbWFrZSB0aGF0IHdvcmsuCj4+Pj4+Pj4+Pj4+Pgo+Pj4+ Pj4+Pj4+Pj4gU28sIGhvdyB0byBtb3ZlIGZvcndhcmQ/IFdlbGwsIEknZCBsaWtlIHRvIHByb3Bv c2UgdGhlIGZvbGxvd2luZzoKPj4+Pj4+Pj4+Pj4+ICgxKSBzdWJtaXQgYWxsIHRoZSBvdGhlciBQ aGFicmljYXRvciByZXZpZXdzIHlvdSBoYXZlIG9wZW4gKHRoZXkgYXJlIG1vc3RseSBnb29kLCBv ciBjbG9zZSB0byBnb29kKSB0byBnaXRodWIuIEdpdGh1YiBpcyBiZWluZyBhY3RpdmVseSBtYW5h Z2VkIGFuZCB3aWxsIG1ha2UgaXQgZmFzdGVyIHRvIGdldCB0aGluZ3MgaXQuIEl0J3MgYSBtdWNo IGJldHRlciB0b29sIGZvciBuZXcgY29udHJpYnV0b3JzIChhbmQgZXZlbiBmcmVxdWVudCBjb250 cmlidXRvcnMgb2Ygc21hbGxpc2ggdGhpbmdzKS4KPj4+Pj4+Pj4+Pj4+ICgyKSBJIHNob3VsZCBk byBhbiB2ZW5kb3IgaW1wb3J0IG9mIDUuMy4wIGZyb20gZ2l0aHViLCBhbmQgZG8gdGhlIG1lcmdl IHRvIGEgYnJhbmNoIGFuZCBwdXNoIHRoYXQgdG8gZ2l0aHViLiBZb3UgY2FuIHRoZW4gbGF5ZXIg b24geW91ciBjaGFuZ2VzIGFuZCB0aG9zZSBjYW4gYmUgcmV2aWV3ZWQgbW9yZSBjbG9zZWx5IGFz IGEgcHVsbCByZXF1ZXN0IGFnYWluc3QgdGhlIGJyYW5jaCBJIHB1c2guIEkgc3VzcGVjdCB0aGF0 IG1vc3Qgb2YgdGhlIGlzc3VlcyBhcmUgc29ydGVkIG91dCBhbHJlYWR5Cj4+Pj4+Pj4+Pj4+PiAo MykgSSdsbCBsYW5kIGl0IHZpYSB0aGF0IHJvdXRlLi4uCj4+Pj4+Pj4+Pj4+Pgo+Pj4+Pj4+Pj4+ Pj4gQW5kLCBpZiB0aGUgc3VtIG9mIHRoZSBvdGhlciBwdWxsIHJlcXVlc3RzIGFuZCB0aGlzIGFy ZSBnb29kIChhbmQgSSBzdXNwZWN0IHRoZXkgd2lsbCBiZSksIHRoZW4gd2UgY2FuIHRhbGsgYWJv dXQgY29tbWl0IGJpdHMgYW5kIHN1Y2guCj4+Pj4+Pj4+Pj4+Pgo+Pj4+Pj4+Pj4+Pj4gSXQncyBl eHBlcmllbmNlcyBsaWtlIHRoaXMgd2hpY2ggaXMgd2h5IEknbSB0cnlpbmcgdG8gc3RhbmQgdXAg Z2l0aHViIHB1bGwgcmVxdWVzdHMgYXMgYSByZWxpYWJsZSB3YXkgdG8gZ2V0IHRoaW5ncyBhbmQg YW5kIHRoZSBiZXN0IHBsYWNlIHRvIHNlbmQgcGVvcGxlLi4uCj4+Pj4+Pj4+Pj4+Pgo+Pj4+Pj4+ Pj4+Pj4gVGhhbmtzIGFnYWluIGZvciBwZXJzaXN0aW5nLCBhbmQgYWxzbyBmb3IgZXhwcmVzc2lu ZyB0aGlzIGNyaXRpY2lzbSB0aGF0IHdlIChob3BlZnVsbHkpIGNhbiB1c2UgdG8gbWFrZSBpdCBi ZXR0ZXIuCj4+Pj4+Pj4+Pj4+Pgo+Pj4+Pj4+Pj4+Pj4gV2FybmVyCj4+Pj4+Pj4+Pj4+Cj4+Pj4+ Pj4+Pj4+IEhlbGxvLgo+Pj4+Pj4+Pj4+Pgo+Pj4+Pj4+Pj4+PiBJJ20gbm90IHRoZSBhdXRob3Ig b2YgRDQxNDIxLiBKdXN0IGFwcGxpZWQgdGhlIHBhdGNoIHRvIHRlc3QgaXQgOCBtb250aHMgYWdv LiBBbmQgcmVjZW50bHkgZGlzY292ZXJlZCB0aGF0IGl0J3Mgc3RpbGwgbm90IGNvbW1pdHRlZC4K Pj4+Pj4+Pj4+Pj4gSSBjYW4ndCBjb3B5IHlvdXIgbWVzc2FnZSB0byBQaGFicmljYXRvciBiZWNh dXNlIGRvbid0IGhhdmUgYW4gYWNjb3VudC4gUGxlYXNlLCBpZiB5b3UgaGF2ZSB0aW1lLCBoZWxw IHRoZSBhdXRob3IgaW4gRDQxNDIxLgo+Pj4+Pj4+Pj4+Cj4+Pj4+Pj4+Pj4gQWggeWVzLiBJJ3Zl IGJlZW4gaW4gdG91Y2ggd2l0aCB0aGUgYXV0aG9yIGZvciBvdGhlciB0aGluZ3MsIGFuZCBzb21l aG93IHRob3VnaHQgaXQgd2FzIHlvdS4uLi4gSSdsbCByZWFjaCBvdXQgdG8gaGltIHZpYSBvdGhl ciBtZWFucy4uLgo+Pj4+Pj4+Pj4+Cj4+Pj4+Pj4+Pj4gV2FybmVy --b1=_JWexQ6bpLKudsw2VBuqTCOLcF6jLLhngbknHlLjCiU Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0 cHg7Ij5IaSBXYXJuZXIsPC9kaXY+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5z LXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij48YnI+PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1mYW1p bHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij48L2Rpdj48ZGl2PjxzcGFu PlNldmVyYWwgdXNlcnMgaGF2ZSBiZWVuIHJ1bm5pbmcgdGhlaXIgc3lzdGVtcyB3aXRoIHRoZSB1 cGRhdGVkIGplbWFsbG9jIGZvciBhIHdoaWxlIG5vdy4gSSd2ZSBiZWVuIHJ1bm5pbmcgbXkgc3lz dGVtcywgYSBkdWFsLXNvY2tldCBOVU1BIHdvcmtzdGF0aW9uIGFuZCBhIGxhcHRvcCAoYm90aCB4 ODZfNjQpLCBmb3Igb3ZlciBhIHllYXIgd2l0aG91dCBpc3N1ZXMuPC9zcGFuPjwvZGl2PjxkaXY+ PGJyPjwvZGl2PjxkaXY+PHNwYW4+TWF5IEkgc3VnZ2VzdCBpbXBvcnRpbmcgdGhlIHVwZGF0ZWQg amVtYWxsb2MgaW50byAxNS1DVVJSRU5UIGZvciB3aWRlciB0ZXN0aW5nPyBJdCdzIGJldHRlciB0 byBoYXZlIGl0IGluIHRoZSB0cmVlIGZvciBhIGxvbmdlciBwZXJpb2Qgb2YgdGltZSBiZWZvcmUg dGhlIDE1LjAgcmVsZWFzZS48L3NwYW4+PC9kaXY+PGRpdj48YnI+PC9kaXY+PHNwYW4+U29ycnkg Zm9yIHRoZSBub2lzZSBhbmQgdGhhbmtzLjwvc3Bhbj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTog QXJpYWwsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPjwvZGl2PjxkaXYgY2xhc3M9InBy b3Rvbm1haWxfc2lnbmF0dXJlX2Jsb2NrIiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5z LXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1p bHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij48YnI+PGRpdiBjbGFzcz0i cHJvdG9ubWFpbF9xdW90ZSI+DQogICAgICAgIE9uIFN1bmRheSwgRGVjZW1iZXIgOHRoLCAyMDI0 IGF0IDc6NDEgUE0sIFdhcm5lciBMb3NoICZsdDtpbXBAYnNkaW1wLmNvbSZndDsgd3JvdGU6PGJy Pg0KICAgICAgICA8YmxvY2txdW90ZSBjbGFzcz0icHJvdG9ubWFpbF9xdW90ZSIgdHlwZT0iY2l0 ZSI+DQogICAgICAgICAgICA8ZGl2IGRpcj0ibHRyIj5HcmVhdCEgSSdsbCB0YWtlIGEgbG9vayBh dCB0aGF0LCBhcyB3ZWxsIGFzIGRvIHRoZSBtZXJnZSB0aGUgdHlwaWNhbCB3YXkgKHdoaWNoIG9u bHkgdGFrZXMgYSBmZXcgbWludXRlcyBub3cgdGhhdCBJJ3ZlIGJvb3RzdHJhcHBlZCB0aGluZ3Mp LiBJJ2xsIGNvbXBhcmUgdGhlIHR3byB0byBzZWUgd2hhdCBkaWZmcyB0aGVyZSBtaWdodCBiZSAo dG8gYWN0IGFzIGEgY3Jvc3MgY2hlY2sgZm9yIGJvdGggbWV0aG9kcykuIEknbGwgdGhlbiBidWls ZCBhIGNvcHkgb2YgdGhlIE5ldGZsaXggZmlybXdhcmUgd2l0aCB0aGUgY2hhbmdlIGFuZCBwdXQg aXQgb24gYSBjb3VwbGUgbWFjaGluZXMgYW5kIHNlZSBpZiB0aGV5IGNhbiBoYW5kbGUgdGhlIGxv YWQgYW5kIGlmIHRoZXJlIGFyZSBhbnkgcGVyZm9ybWFuY2UgcmVncmVzc2lvbnMuIEkgZG9uJ3Qg ZXhwZWN0IGFueSwgc2luY2UgbWFsbG9jIHR5cGljYWxseSBkb2Vzbid0IGFwcGVhciBpbiB0aGUg ZmxhbWUgZ3JhcGhzIGFzICJ2aXNpYmxlIiwgYnV0IHlvdSBuZXZlciBrbm93LjxkaXY+PGJyPjwv ZGl2PjxkaXY+U28sIG9uY2UgdGhhdCdzIGRvbmUsIGFuZCBJIGV4cGVjdCBpdCB0byBiZSBkb25l IHRoaXMgd2VlaywgSSdsbCBwdXNoIGl0IGludG8gbWFpbiB3aXRoIGJvdGggdGhlIHByb3BlciB2 ZW5kb3IgYnJhbmNoIG1lcmdlIGNvbW1pdHMgYXMgd2VsbCBhcyBhbiBhY2tub3dsZWRnZW1lbnQg Zm9yIHRoaXMgcHVsbCByZXF1ZXN0IGFuZCB5b3VyIHdvcmsgdG8gbW92ZSBpdCBmb3J3YXJkIChJ J20ganVzdCB2ZXJpZnlpbmcgdGhlIHR5cGljYWwgcHJvY2VzcyB3aWxsIHByb2R1Y2UgdGhlIHNh bWUgcmVzdWx0cyBhbmQgdGhlIHR5cGljYWwgcHJvY2VzcyBkb2Vzbid0IHRha2UgYSBsb25nIHRp bWUsIGV0YykuPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5XYXJuZXI8L2Rpdj48L2Rpdj48YnI+ PGRpdiBjbGFzcz0iZ21haWxfcXVvdGUgZ21haWxfcXVvdGVfY29udGFpbmVyIj48ZGl2IGNsYXNz PSJnbWFpbF9hdHRyIiBkaXI9Imx0ciI+T24gU3VuLCBEZWMgOCwgMjAyNCBhdCA5OjAz4oCvQU0g TWluc29vIENob28gJmx0OzxhIGhyZWY9Im1haWx0bzptaW5zb29jaG9vMDEyMkBwcm90b24ubWUi IHJlbD0ibm9yZWZlcnJlciBub2ZvbGxvdyBub29wZW5lciI+bWluc29vY2hvbzAxMjJAcHJvdG9u Lm1lPC9hPiZndDsgd3JvdGU6PGJyPjwvZGl2PjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW46MHB4 IDBweCAwcHggMC44ZXg7Ym9yZGVyLWxlZnQ6MXB4IHNvbGlkIHJnYigyMDQsMjA0LDIwNCk7cGFk ZGluZy1sZWZ0OjFleCIgY2xhc3M9ImdtYWlsX3F1b3RlIj48ZGl2PkkgcmVzb2x2ZWQgbWVyZ2Ug Y29uZmxpY3QgYnkgcmViYXNpbmcgbWFpbi4gV2hhdCdzIG5leHQ/PC9kaXY+PGRpdiBzdHlsZT0i Zm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7IGNvbG9yOiBy Z2IoMCwgMCwgMCk7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsiPjxicj48 L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IGZvbnQtc2l6 ZTogMTRweDsgY29sb3I6IHJnYigwLCAwLCAwKTsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwg MjU1LCAyNTUpOyI+PHNwYW4+PGEgdGFyZ2V0PSJfYmxhbmsiIGhyZWY9Imh0dHBzOi8vZ2l0aHVi LmNvbS9mcmVlYnNkL2ZyZWVic2Qtc3JjL3B1bGwvMTMzNyIgcmVsPSJub3JlZmVycmVyIG5vZm9s bG93IG5vb3BlbmVyIj5odHRwczovL2dpdGh1Yi5jb20vZnJlZWJzZC9mcmVlYnNkLXNyYy9wdWxs LzEzMzc8L2E+PC9zcGFuPjxicj48L2Rpdj48ZGl2Pg0KICAgICAgICBPbiBTdW5kYXksIERlY2Vt YmVyIDFzdCwgMjAyNCBhdCAyOjA1IEFNLCBXYXJuZXIgTG9zaCAmbHQ7PGEgdGFyZ2V0PSJfYmxh bmsiIGhyZWY9Im1haWx0bzppbXBAYnNkaW1wLmNvbSIgcmVsPSJub3JlZmVycmVyIG5vZm9sbG93 IG5vb3BlbmVyIj5pbXBAYnNkaW1wLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiAgICAgICAgPGJs b2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQogICAgICAgICAgICA8ZGl2IGRpcj0ibHRyIj48ZGl2IGRp cj0ibHRyIj4oc29ycnkgdG8gZm9sbG93IHVwIHRvIG15IG93biBlbWFpbCBhbmQgdG9wcG9zdGlu Zyk8L2Rpdj48ZGl2IGRpcj0ibHRyIj48YnI+PC9kaXY+PGRpdj5JIGdvdCB0aGUgdmVuZG9yIGJy YW5jaCBib290c3RyYXBwZWQ6IEkgY3JlYXRlZCB2ZW5kb3IvamVtYWxsb2MgYW5kIHRhZ2dlZCB2 ZW5kb3IvamVtYWxsb2MvNS4yLjEsPC9kaXY+PGRpdj5hbmQgY3JlYXRlZCBhIG1lcmdlIGNvbW1p dCBmcm9tIHRoYXQgYnJhbmNoIHRvIG1haW4uIEkgaGFkIHRvIHR3ZWFrIHRoZTwvZGl2PjxkaXY+ RlJFRUJTRC1YbGlzdCBhIGxpdHRsZS5JJ3ZlIG5vdCB1cGRhdGVkIHRoZSBvdGhlciB0d28gRlJF RUJTRC0qIGZpbGVzLCBidXQgdGhlIHN0ZXBzIHdlcmU8L2Rpdj48ZGl2PmRvY3VtZW50ZWQgaW4g dGhlIGNvbW1pdCBtZXNzYWdlcyAodGhlIHZlbmRvciBicmFuY2ggb25lIGlzIGVzcGVjaWFsbHkg bG9uZyBhbmQ8L2Rpdj48ZGl2Pmxpa2VseSBzaG91bGQgbWlncmF0ZSBpbnRvIHRoZSBkZXZlbG9w ZXIgaGFuZGJvb2spLiBGUkVFQlNELXVwZGF0ZSBpcyBiYXNpY2FsbHk8L2Rpdj48ZGl2PmEgc2hl bGwgc2NyaXB0IHRvIGRvIHRoZSBzYW1lIHRoaW5nIHRoYXQgZ2l0IHN1YnRyZWUgbWVyZ2UgZG9l cywgdGhvdWdoIEknbSBzdXJlIHNvbWU8L2Rpdj48ZGl2PnR3ZWFrcyBjb3VsZCBoZWxwIHRoZSBu ZXh0IHRpbWUgKGlmIHRoZXJlIGlzIGEgbmV4dCB0aW1lLCBqZW1hbGxvYyB1cHN0cmVhbSBzZWVt cyB0bzwvZGl2PjxkaXY+aGF2ZSBzbG93ZWQgd2F5IGRvd24gb2YgbGF0ZSkuPC9kaXY+PGRpdj48 YnI+PC9kaXY+PGRpdj5OZXh0IHVwLEknbGwgY3JlYXRlIDUuMy4wIGltcG9ydCBvbiB0aGUgdmVu ZG9yIGJyYW5jaCwgZG8gdGhlIG1lcmdlIGFuZCBzdGFydCB0ZXN0aW5nIChpdCB3aWxsIGJlPC9k aXY+PGRpdj5NaW5zb28ncyBwdWxsIHJlcXVlc3QsIHJlYmFzZWQsIHdpdGggYW55IGNvbmZsaWN0 cyByZXNvbHZlZCBhbmQgbWVyZ2UgY29tbWl0IHJlY29yZGVkKS48L2Rpdj48ZGl2PkJ1dCB0aGF0 IHdpbGwgaGF2ZSB0byBiZSB0b21vcnJvdyBvciBtb3JlIGxpa2VseSBkdXJpbmcgdGhlIHdvcmsg d2Vlay4gSSdtIHRvbyB0aXJlZCB0b25pZ2h0PC9kaXY+PGRpdj50byBnZXQgaXQgcmlnaHQgYXQg dGhlIG1vbWVudC48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PkFuZCBhIHNwZWNpYWwgdGhhbmtz IHRvIGVtYXN0ZSBmb3IgZ2l2aW5nIGJ6IHRoZSByaWdodCByZWNpcGUgZm9yIGRvaW5nIHRoZSBz dWJ0cmVlIG1lcmdlPC9kaXY+PGRpdj53L28gZ2l0IHN1YnRyZWUgZm9yIGhpcyB3b3JrIG9uIHRo ZSBsaW51eCB3aWZpIGRyaXZlcnMgaW4gdGhlIHRyZWUuPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRp dj5XYXJuZXI8L2Rpdj48YnI+PGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPjxkaXYgZGlyPSJsdHIi IGNsYXNzPSJnbWFpbF9hdHRyIj5PbiBTYXQsIE5vdiAzMCwgMjAyNCBhdCA5OjM44oCvUE0gV2Fy bmVyIExvc2ggJmx0OzxhIHRhcmdldD0iX2JsYW5rIiByZWw9Im5vcmVmZXJyZXIgbm9mb2xsb3cg bm9vcGVuZXIiIGhyZWY9Im1haWx0bzppbXBAYnNkaW1wLmNvbSI+aW1wQGJzZGltcC5jb208L2E+ Jmd0OyB3cm90ZTo8YnI+PC9kaXY+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHls ZT0ibWFyZ2luOjBweCAwcHggMHB4IDAuOGV4O2JvcmRlci1sZWZ0OjFweCBzb2xpZCByZ2IoMjA0 LDIwNCwyMDQpO3BhZGRpbmctbGVmdDoxZXgiPjxkaXYgZGlyPSJsdHIiPlllYSwgSSBuZWVkIHRv IGdldCBhIGNvcHkgb2YgamVtYWxsb2MgNS4zLjAgYW5kIDUuMi4xIHRvIHRyeSB0byAnYm9vdHN0 cmFwJyB0aGUgdmVuZG9yIGJyYW5jaC48ZGl2PlRoZW4gSSBuZWVkIHRvIGJvb3RzdHJhcCBpdC4u LjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+SSBqdXN0IGRpZCB0aGUgc2FtZSB3aXRoIGVkazIg KHdoaWNoIGhhZCBhIHZlbmRvciBicmFuY2gsIGJ1dCBoYWRuJ3QgYmVlbiB1cGRhdGVkIHNpbmNl IHN2biB0aW1lcykuPC9kaXY+PGRpdj5Ib3dldmVyLCBqZW1hbGxvYyBkb2Vzbid0IGhhdmUgYSB2 ZW5kb3IgYnJhbmNoIHlldCwgc28gSSdsbCBoYXZlIHRvIGNyZWF0ZSB0aGF0LCBidXQgSSdsbCBz dGFydCB3aXRoIHRoZTwvZGl2PjxkaXY+Y3VycmVudCB2ZXJzaW9uIHJhdGhlciB0aGFuIGRvaW5n IGZ1bGwgaGlzdG9yeS4uLiAgU28gSSdsbCBzdGFydCB0aGVyZS48L2Rpdj48ZGl2PkkgYWxzbyBq dXN0IGRpZCBhd2sgYW5kIGx1YSwgc28gb25jZSBJIGhhdmUgdGhpbmdzIGJvb3RzdHJhcHBlZCwg SSdsbCBiZSBhYmxlIHRvIGFkZCA1LjMuMCBhbmQgdGhlbiBsYXllciBNaW5zb28ncyAgb248L2Rp dj48ZGl2PnRvcCBvZiB0aGF0IGFuZCB0aGVuIHN0YXJ0IHRlc3RpbmcgaXQgc29tZWhvdy48L2Rp dj48ZGl2Pjxicj48L2Rpdj48ZGl2Pk1hbGxvYyBtYWtlcyBtZSBuZXJ2b3VzIHRvIHRvdWNoLCBo b25lc3RseSwgYnV0IEknbGwgZ2l2ZSBpdCBhIGdvIGFuZCB0ZXN0IGJvb3Qgb24gbXkgc3lzdGVt IGFuZDwvZGl2PjxkaXY+bWF5YmUgc2VlIGlmIHdlIGNhbiBzdXJ2aXZlIGEgd29ya2xvYWQgYXQg d29yayB3L28gcmVncmVzc2lvbnMuLi4gQnV0IEkgY2FuJ3QgZG8gYSBmdWxsIHRlc3Qgd2l0aCBs b3RzPGJyPjwvZGl2PjxkaXY+b2YgbWFjaGluZXMgdW50aWwgYWZ0ZXIgdGhlIGZpcnN0IG9mIHRo ZSB5ZWFyICh0aG91Z2ggSSBjYW4gZG8gYSBjb3VwbGUgZm9yIGEgZmV3IGRheXMgYmVmb3JlIHRo ZW4pLjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+U28gbXkgbmV4dCBzdGVwIGlzIHRvIGJvb3Rz dHJhcCB0aGUgdmVuZG9yIGJyYW5jaC4uLiBJJ2xsIGdpdmUgdGhhdCBhIHRyeSB0b25pZ2h0Ljwv ZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+V2FybmVyPC9kaXY+PC9kaXY+PGJyPjxkaXYgY2xhc3M9 ImdtYWlsX3F1b3RlIj48ZGl2IGRpcj0ibHRyIiBjbGFzcz0iZ21haWxfYXR0ciI+T24gU2F0LCBO b3YgMzAsIDIwMjQgYXQgODoyNuKAr1BNIE1pbnNvbyBDaG9vICZsdDs8YSB0YXJnZXQ9Il9ibGFu ayIgcmVsPSJub3JlZmVycmVyIG5vZm9sbG93IG5vb3BlbmVyIiBocmVmPSJtYWlsdG86bWluc29v Y2hvbzAxMjJAcHJvdG9uLm1lIj5taW5zb29jaG9vMDEyMkBwcm90b24ubWU8L2E+Jmd0OyB3cm90 ZTo8YnI+PC9kaXY+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2lu OjBweCAwcHggMHB4IDAuOGV4O2JvcmRlci1sZWZ0OjFweCBzb2xpZCByZ2IoMjA0LDIwNCwyMDQp O3BhZGRpbmctbGVmdDoxZXgiPjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1z ZXJpZjsgZm9udC1zaXplOiAxNHB4OyBjb2xvcjogcmdiKDAsIDAsIDApOyBiYWNrZ3JvdW5kLWNv bG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7Ij5JIGhhdmUgYWxyZWFkeSBzdWJtaXR0ZWQgUFIgb24g Z2l0aHViICg8c3Bhbj48YSB0YXJnZXQ9Il9ibGFuayIgcmVsPSJub3JlZmVycmVyIG5vZm9sbG93 IG5vb3BlbmVyIiBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vZnJlZWJzZC9mcmVlYnNkLXNyYy9w dWxsLzEzMzciPmh0dHBzOi8vZ2l0aHViLmNvbS9mcmVlYnNkL2ZyZWVic2Qtc3JjL3B1bGwvMTMz NzwvYT48L3NwYW4+KSBhbmQgcGhhYnJpY2F0b3IgKDxzcGFuPjxhIHRhcmdldD0iX2JsYW5rIiBy ZWw9Im5vcmVmZXJyZXIgbm9mb2xsb3cgbm9vcGVuZXIiIGhyZWY9Imh0dHBzOi8vcmV2aWV3cy5m cmVlYnNkLm9yZy9ENDE0MjEiPmh0dHBzOi8vcmV2aWV3cy5mcmVlYnNkLm9yZy9ENDE0MjE8L2E+ PC9zcGFuPikuIEkgZG9uJ3QgaGF2ZSBhY2Nlc3MgKGNvbW1pdCBiaXQpIHRvIGZyZWVic2QgZ2l0 IHJlcG8sIHNvIHRoZXJlIGlzIG5vdGhpbmcgSSBjYW4gZG8gYXQgdGhpcyBwb2ludCBzaW5jZSB2 ZW5kb3IgaW1wb3J0IGFuZCBsYW5kaW5nIHBhdGNoZXMgcmVxdWlyZXMgY29tbWl0IGJpdC48YnI+ PC9kaXY+PGRpdj4NCiAgICAgICAgT24gU2F0dXJkYXksIE5vdmVtYmVyIDMwdGgsIDIwMjQgYXQg MTo0MiBQTSwgY2dsb2dpYyAmbHQ7PGEgdGFyZ2V0PSJfYmxhbmsiIHJlbD0ibm9yZWZlcnJlciBu b2ZvbGxvdyBub29wZW5lciIgaHJlZj0ibWFpbHRvOmNnbG9naWNAcHJvdG9ubWFpbC5jb20iPmNn bG9naWNAcHJvdG9ubWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQogICAgICAgIDxibG9ja3F1 b3RlIHR5cGU9ImNpdGUiPg0KICAgICAgICAgICAgPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6QXJp YWwsc2Fucy1zZXJpZjtmb250LXNpemU6MTRweCI+SSBzZWUsIGl0IGhhcHBlbnMuPC9kaXY+PGRp diBzdHlsZT0iZm9udC1mYW1pbHk6QXJpYWwsc2Fucy1zZXJpZjtmb250LXNpemU6MTRweCI+PHNw YW4+TWF5YmUgYW5vdGhlciBjb21taXR0ZXIgd2lsbCB2b2x1bnRlZXIgdG8gZG8gdGhlIHVwZGF0 ZS48L3NwYW4+PGRpdj5JIGhvcGUgaXQgd2lsbCBtYWtlIGl0cyB3YXkgaW50byAxNS4wIHJlbGVh c2UuPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5UaGFua3MuPC9kaXY+PC9kaXY+PGRpdj4NCiAg ICAgICAgT24gRnJpZGF5LCBOb3ZlbWJlciAyOXRoLCAyMDI0IGF0IDk6MzggUE0sIFdhcm5lciBM b3NoICZsdDs8YSB0YXJnZXQ9Il9ibGFuayIgcmVsPSJub3JlZmVycmVyIG5vZm9sbG93IG5vb3Bl bmVyIiBocmVmPSJtYWlsdG86aW1wQGJzZGltcC5jb20iPmltcEBic2RpbXAuY29tPC9hPiZndDsg d3JvdGU6PGJyPg0KICAgICAgICA8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCiAgICAgICAgICAg IDxkaXYgZGlyPSJsdHIiPkkndmUgYmVlbiBzd2FtcGVkLiB3ZSBuZWVkIHRvIGJvb3RzdHJhcCB0 aGUgdmVuZG9yIGJyYW5jaCwgYW5kIHRoZSB3YXkgcHJpb3IgdXBkYXRlcyB3ZXJlIGRvbmU8ZGl2 Pmlzbid0IHNvIGdyZWF0LiA8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pldhcm5lcjwvZGl2Pjwv ZGl2Pjxicj48ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+PGRpdiBkaXI9Imx0ciIgY2xhc3M9Imdt YWlsX2F0dHIiPk9uIE1vbiwgTm92IDI1LCAyMDI0IGF0IDI6MjHigK9BTSBjZ2xvZ2ljICZsdDs8 YSB0YXJnZXQ9Il9ibGFuayIgcmVsPSJub3JlZmVycmVyIG5vZm9sbG93IG5vb3BlbmVyIiBocmVm PSJtYWlsdG86Y2dsb2dpY0Bwcm90b25tYWlsLmNvbSI+Y2dsb2dpY0Bwcm90b25tYWlsLmNvbTwv YT4mZ3Q7IHdyb3RlOjxicj48L2Rpdj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0 eWxlPSJtYXJnaW46MHB4IDBweCAwcHggMC44ZXg7Ym9yZGVyLWxlZnQ6MXB4IHNvbGlkIHJnYigy MDQsMjA0LDIwNCk7cGFkZGluZy1sZWZ0OjFleCI+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6QXJp YWwsc2Fucy1zZXJpZjtmb250LXNpemU6MTRweCI+SGVsbG8gZ3V5cyw8L2Rpdj48ZGl2IHN0eWxl PSJmb250LWZhbWlseTpBcmlhbCxzYW5zLXNlcmlmO2ZvbnQtc2l6ZToxNHB4Ij48YnI+PC9kaXY+ PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6QXJpYWwsc2Fucy1zZXJpZjtmb250LXNpemU6MTRweCI+ SG93IHRoZSB1cGRhdGUgb2YgamVtYWxsb2MgaXMgZ29pbmc/IEl0J3MgTm92ZW1iZXIgbm93Ljwv ZGl2PjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkFyaWFsLHNhbnMtc2VyaWY7Zm9udC1zaXplOjE0 cHgiPjxicj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTpBcmlhbCxzYW5zLXNlcmlmO2Zv bnQtc2l6ZToxNHB4Ij5UaGFua3MuPC9kaXY+PGRpdj4NCiAgICAgICAgT24gTW9uZGF5LCBKdWx5 IDIybmQsIDIwMjQgYXQgNzowMiBQTSwgTWluc29vIENob28gJmx0OzxhIHRhcmdldD0iX2JsYW5r IiByZWw9Im5vcmVmZXJyZXIgbm9mb2xsb3cgbm9vcGVuZXIiIGhyZWY9Im1haWx0bzptaW5zb29j aG9vMDEyMkBwcm90b24ubWUiPm1pbnNvb2Nob28wMTIyQHByb3Rvbi5tZTwvYT4mZ3Q7IHdyb3Rl Ojxicj4NCiAgICAgICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQogICAgICAgICAgICA8ZGl2 IHN0eWxlPSJmb250LWZhbWlseTpBcmlhbCxzYW5zLXNlcmlmO2ZvbnQtc2l6ZToxNHB4Ij5GaXJz dCwgc29ycnkgZm9yIGxhdGUgcmVzcG9uc2UuPC9kaXY+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6 QXJpYWwsc2Fucy1zZXJpZjtmb250LXNpemU6MTRweCI+PGJyPjwvZGl2PjxkaXYgc3R5bGU9ImZv bnQtZmFtaWx5OkFyaWFsLHNhbnMtc2VyaWY7Zm9udC1zaXplOjE0cHgiPmNnbG9naWMsIHRoYW5r IHlvdSBmb3IgYnJpbmdpbmcgdXAgdGhpcyBpc3N1ZSBhZ2FpbiBzaW5jZSBJIG5lYXJseSBmb3Jn b3QgdGhhdCB0aGlzIGlzc3VlIHdhcyBzdGlsbCBvcGVuLjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQt ZmFtaWx5OkFyaWFsLHNhbnMtc2VyaWY7Zm9udC1zaXplOjE0cHgiPjxicj48L2Rpdj48ZGl2IHN0 eWxlPSJmb250LWZhbWlseTpBcmlhbCxzYW5zLXNlcmlmO2ZvbnQtc2l6ZToxNHB4Ij5XYXJuZXIs IGFzIEkgY2FuJ3QgYWNjZXNzIHRvIG15IEZyZWVCU0QgaW5zdGFuY2UgdW50aWwgdGhlIGVuZCBv ZiBBdWd1c3QsIGJ1dCBJIGNhbiBzdGlsbCBlZGl0IGFuZCBwdXNoIHRoZSBjb2RlIHRocm91Z2gg bXkgQXJtIE1hYy4gVGhpcyBtZWFucyB0aGF0IEkgY2FuJ3QgdGVzdCB0aGUgdXBkYXRlZCBjb2Rl IG9uIG15IG1hY2hpbmUsIGJ1dCBJIGNhbiBqb2luIHRoZSByZXZpZXcgcHJvY2VzcyBhbmQgbGlz dGVuIHRvIGNoYW5nZSBwcm9wb3NhbHMuPC9kaXY+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6QXJp YWwsc2Fucy1zZXJpZjtmb250LXNpemU6MTRweCI+PGJyPjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQt ZmFtaWx5OkFyaWFsLHNhbnMtc2VyaWY7Zm9udC1zaXplOjE0cHgiPkknbGwgb3BlbiBhIEdpdGh1 YiBQUiBpbiBhIGZldyBob3Vycy4gKFRoZSBwaGFicmljYXRvciByZXZpZXcgd2lsbCBzdGF5IG9w ZW5lZCBqdXN0IGluIGNhc2UpPC9kaXY+PGRpdj4NCiAgICAgICAgT24gTW9uZGF5LCBKdWx5IDIy bmQsIDIwMjQgYXQgNTowOCBBTSwgV2FybmVyIExvc2ggJmx0OzxhIHRhcmdldD0iX2JsYW5rIiBy ZWw9Im5vcmVmZXJyZXIgbm9mb2xsb3cgbm9vcGVuZXIiIGhyZWY9Im1haWx0bzppbXBAYnNkaW1w LmNvbSI+aW1wQGJzZGltcC5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQogICAgICAgIDxibG9ja3F1 b3RlIHR5cGU9ImNpdGUiPg0KICAgICAgICAgICAgPGRpdiBkaXI9Imx0ciI+PGRpdiBkaXI9Imx0 ciI+PGJyPjwvZGl2Pjxicj48ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+PGRpdiBkaXI9Imx0ciIg Y2xhc3M9ImdtYWlsX2F0dHIiPk9uIFN1biwgSnVsIDIxLCAyMDI0IGF0IDI6MDPigK9QTSBjZ2xv Z2ljICZsdDs8YSB0YXJnZXQ9Il9ibGFuayIgcmVsPSJub3JlZmVycmVyIG5vZm9sbG93IG5vb3Bl bmVyIiBocmVmPSJtYWlsdG86Y2dsb2dpY0Bwcm90b25tYWlsLmNvbSI+Y2dsb2dpY0Bwcm90b25t YWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj48L2Rpdj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxf cXVvdGUiIHN0eWxlPSJtYXJnaW46MHB4IDBweCAwcHggMC44ZXg7Ym9yZGVyLWxlZnQ6MXB4IHNv bGlkIHJnYigyMDQsMjA0LDIwNCk7cGFkZGluZy1sZWZ0OjFleCI+PGRpdiBzdHlsZT0iZm9udC1m YW1pbHk6QXJpYWwsc2Fucy1zZXJpZjtmb250LXNpemU6MTRweCI+PGJyPjwvZGl2PjxkaXY+DQog ICAgICAgIE9uIFN1bmRheSwgSnVseSAyMXN0LCAyMDI0IGF0IDY6NTQgQU0sIFdhcm5lciBMb3No ICZsdDs8YSB0YXJnZXQ9Il9ibGFuayIgcmVsPSJub3JlZmVycmVyIG5vZm9sbG93IG5vb3BlbmVy IiBocmVmPSJtYWlsdG86aW1wQGJzZGltcC5jb20iPmltcEBic2RpbXAuY29tPC9hPiZndDsgd3Jv dGU6PGJyPg0KICAgICAgICA8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCiAgICAgICAgICAgIDxk aXYgZGlyPSJsdHIiPjxkaXYgZGlyPSJsdHIiPjxicj48L2Rpdj48YnI+PGRpdiBjbGFzcz0iZ21h aWxfcXVvdGUiPjxkaXYgZGlyPSJsdHIiIGNsYXNzPSJnbWFpbF9hdHRyIj5PbiBTYXQsIEp1bCAy MCwgMjAyNCBhdCAxOjU54oCvQU0gY2dsb2dpYyAmbHQ7PGEgdGFyZ2V0PSJfYmxhbmsiIHJlbD0i bm9yZWZlcnJlciBub2ZvbGxvdyBub29wZW5lciIgaHJlZj0ibWFpbHRvOmNnbG9naWNAcHJvdG9u bWFpbC5jb20iPmNnbG9naWNAcHJvdG9ubWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8YnI+PC9kaXY+ PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4 IDAuOGV4O2JvcmRlci1sZWZ0OjFweCBzb2xpZCByZ2IoMjA0LDIwNCwyMDQpO3BhZGRpbmctbGVm dDoxZXgiPjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsgZm9udC1z aXplOiAxNHB4OyBjb2xvcjogcmdiKDAsIDAsIDApOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1 LCAyNTUsIDI1NSk7Ij5IZWxsbyBGcmVlQlNEIGNvbW11bml0eSw8L2Rpdj48ZGl2IHN0eWxlPSJm b250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsgY29sb3I6IHJn YigwLCAwLCAwKTsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyI+PGJyPjwv ZGl2PjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsgZm9udC1zaXpl OiAxNHB4OyBjb2xvcjogcmdiKDAsIDAsIDApOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAy NTUsIDI1NSk7Ij48c3BhbiBzdHlsZT0iZGlzcGxheTogaW5saW5lOyBiYWNrZ3JvdW5kLWNvbG9y OiByZ2IoMjU1LCAyNTUsIDI1NSk7Ij5BZnRlciA8L3NwYW4+PHNwYW4gc3R5bGU9ImJhY2tncm91 bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsiPkphc29uIEV2YW5zIHN0ZXBwZWQgYXNpZGUg ZnJvbSBtYWludGFpbmluZyBqZW1hbGxvYyBpbiBGcmVlQlNELCBpdCdzIG5vdCB1cGRhdGluZyBp biB0aW1lIGFueW1vcmUuPC9zcGFuPjxicj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTog QXJpYWwsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsgY29sb3I6IHJnYigwLCAwLCAwKTsg YmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyI+VmVyc2lvbiA1LjMuMCB3YXMg cmVsZWFzZWQgPHNwYW4+TWF5IDYsIDIwMjIgYW5kIEZyZWVCU0Qgc3RpbGwgbm90IGltcG9ydGVk IGl0IGludG8gdGhlIHRyZWUuPC9zcGFuPjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBB cmlhbCwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyBjb2xvcjogcmdiKDAsIDAsIDApOyBi YWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7Ij48c3Bhbj48YnI+PC9zcGFuPjwv ZGl2PjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsgZm9udC1zaXpl OiAxNHB4OyBjb2xvcjogcmdiKDAsIDAsIDApOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAy NTUsIDI1NSk7Ij5UaGVyZSBpcyBhIHBlbmRpbmcgcmV2aWV3IDxzcGFuPjxhIHRhcmdldD0iX2Js YW5rIiByZWw9Im5vcmVmZXJyZXIgbm9mb2xsb3cgbm9vcGVuZXIiIGhyZWY9Imh0dHBzOi8vcmV2 aWV3cy5mcmVlYnNkLm9yZy9ENDE0MjEiPmh0dHBzOi8vcmV2aWV3cy5mcmVlYnNkLm9yZy9ENDE0 MjE8L2E+IGZyb20gPHNwYW4+QXVnIDExLCAyMDIzLjwvc3Bhbj48L3NwYW4+PC9kaXY+PGRpdiBz dHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7IGNv bG9yOiByZ2IoMCwgMCwgMCk7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsi PjxzcGFuPjxzcGFuPkknbSBzdWNjZXNzZnVsbHkgcnVubmluZyBGcmVlQlNEL2FtZDY0IHN5c3Rl bSB3aXRoIEQ0MTQyMSBhcHBsaWVkIGZvciA4IG1vbnRocywgYXMgd2VsbCBhcyBtYW55IG90aGVy IHBlb3BsZS48L3NwYW4+PC9zcGFuPjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlh bCwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyBjb2xvcjogcmdiKDAsIDAsIDApOyBiYWNr Z3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7Ij48c3Bhbj48c3Bhbj48YnI+PC9zcGFu Pjwvc3Bhbj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7 IGZvbnQtc2l6ZTogMTRweDsgY29sb3I6IHJnYigwLCAwLCAwKTsgYmFja2dyb3VuZC1jb2xvcjog cmdiKDI1NSwgMjU1LCAyNTUpOyI+PHNwYW4+PHNwYW4+Q2FuIGl0IGJlIHJldmlld2VkIGFuZCBj b21taXR0ZWQgdG8gQ1VSUkVOVD88L3NwYW4+PC9zcGFuPjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQt ZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyBjb2xvcjogcmdiKDAs IDAsIDApOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7Ij48c3Bhbj48c3Bh bj5PciwgaWYgdGhlcmUgaXMgbm8gY29tbWl0dGVycyB3aWxsaW5nIHRvIGRvIGl0LCBjYW4gY29t bWl0IGJpdCBiZSBnaXZlbiB0byBzdWJtaXR0ZXIgb3IgYW5vdGhlciBwZXJzb24gd2lsbGluZyB0 byBkbyB0aGlzPzwvc3Bhbj48L3NwYW4+PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IEFy aWFsLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGJh Y2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsiPjxzcGFuPjxzcGFuPjxicj48L3Nw YW4+PC9zcGFuPjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJp ZjsgZm9udC1zaXplOiAxNHB4OyBjb2xvcjogcmdiKDAsIDAsIDApOyBiYWNrZ3JvdW5kLWNvbG9y OiByZ2IoMjU1LCAyNTUsIDI1NSk7Ij48c3Bhbj48c3Bhbj48c3Bhbj5JdCdzIHZlcnkgZGlzYXBw b2ludGluZyB3aGVuIHVzZXJzIHNwZW5kIHRoZWlyIHRpbWUgdG8gZmlsbCBzdWNoIGdhcHMgYW5k IHRoZWlyIGVmZm9ydHMganVzdCBpZ25vcmVkIGJ5IHRoZSBkZXZlbG9wZXJzLjwvc3Bhbj48YnI+ PC9zcGFuPjwvc3Bhbj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMt c2VyaWY7IGZvbnQtc2l6ZTogMTRweDsgY29sb3I6IHJnYigwLCAwLCAwKTsgYmFja2dyb3VuZC1j b2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyI+PHNwYW4+PHNwYW4+PHNwYW4+PHNwYW4+RXZlcnkg eWVhciBGcmVlQlNEIENvbW11bml0eSBTdXJ2ZXkgYXNraW5nIGFib3V0IHVzZXIgZXhwZXJpZW5j ZSBpbiBjb250cmlidXRpbmcgdG8gRnJlZUJTRC4gPC9zcGFuPjxicj48L3NwYW4+PC9zcGFuPjwv c3Bhbj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IGZv bnQtc2l6ZTogMTRweDsgY29sb3I6IHJnYigwLCAwLCAwKTsgYmFja2dyb3VuZC1jb2xvcjogcmdi KDI1NSwgMjU1LCAyNTUpOyI+PHNwYW4+PHNwYW4+PHNwYW4+PHNwYW4+SGVyZSB5b3UgY2FuIHNl ZSBhbiBleGFtcGxlIG9mIHN1Y2ggY29udHJpYnV0aW5nLjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwv c3Bhbj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IGZv bnQtc2l6ZTogMTRweDsgY29sb3I6IHJnYigwLCAwLCAwKTsgYmFja2dyb3VuZC1jb2xvcjogcmdi KDI1NSwgMjU1LCAyNTUpOyI+PHNwYW4+PHNwYW4+PHNwYW4+PC9zcGFuPjwvc3Bhbj48L3NwYW4+ PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBmb250LXNp emU6IDE0cHg7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUs IDI1NSwgMjU1KTsiPjxzcGFuPjxicj48L3NwYW4+PC9kaXY+PC9ibG9ja3F1b3RlPjxkaXY+PGJy PjwvZGl2PjxkaXY+Rmlyc3QsIHRoYW5rIHlvdSBmb3IgYmVpbmcgcGVyc2lzdGVudCBhbmQgY29u dGludWluZyB0byBicmluZyBpdCB1cC4gSXQncyBpbXBvcnRhbnQgdG8gZG8gdGhhdCB0byBtYWtl IHN1cmUgdGhpcyAoYW5kIHlvdXIgbWFueSBvdGhlcikgY29udHJpYnV0aW9uIGRvZXNuJ3QgZmFs bCBvbiB0aGUgZmxvb3IuPGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+QW5kIHRvIGJlIGZh aXIsIHdlJ3JlIG9ubHkgMyBtb250aHMgc2luY2UgdGhlIGxhc3QgdXBkYXRlLiBTdGlsbCwgcXVp dGUgYSBiaXQgbG9uZ2VyIHRoYW4geW91IHNob3VsZCBoYXZlIHRvIHdhaXQsIGJ1dCBub3QgbmVh cmx5IHRoZSB5ZWFyIHRoZSBvcmlnaW5hbCBkYXRlIHN1Z2dlc3RzLjxicj48L2Rpdj48ZGl2Pjxi cj48L2Rpdj48ZGl2PkFuZCB0aGlzIGlzIGEgcGVyZmVjdCBzdG9ybSBvZiAiaG93IHRoZSBwcm9q ZWN0IGlzIGJhZCBhdCBhY2NlcHRpbmcgY29udHJpYnV0aW9ucyI6PC9kaXY+PGRpdj4oMSkgVGhl IG9yaWdpbmFsIHN1Ym1pc3Npb24gd2FzIGNsb3NlIHRvIHRoZSAxNCBicmFuY2ggY3JlYXRpb24g dGltZS4gVGhpcyBtZWFudCB0aGF0IHdlIHdlcmVuJ3Qgd2VsbCBwcmVwYXJlZCB0byBsb29rIGF0 IGl0IHNpbmNlIGl0IGlzIHN1Y2ggYW4gaW52YXNpdmUgY2hhbmdlIChhdCBsZWFzdCBvbiBpdHMg c3VyZmFjZSkuIEl0IGFsc28gc2xvd2VkIHRoZSBpbml0aWFsIHJlc3BvbnNlLi4uPGJyPjwvZGl2 PjxkaXY+KDIpIFRoZXJlIHdhcyBhIG51bWJlciBvZiBiYWNrIGFuZCBmb3J0aCByZXF1ZXN0cyBm b3IgY2hhbmdlcywgd2hpY2ggdG9vayB0aW1lIHRvIHNvcnQgb3V0Li4uPC9kaXY+PGRpdj4oMykg VGhlIHNpemUgb2YgdGhpcyBpcyBodWdlLCB3ZWxsIGJleW9uZCB0aGUgY2FwYWNpdHkgb2YgUGhh YnJpY2F0b3IgdG8gcmV2aWV3IGFjY3VyYXRlbHkuLi48L2Rpdj48ZGl2Pig0KSBJdCdzIGEgdmVu ZG9yIGltcG9ydC4gVGhhdCBtZWFucyB3ZSBjYW4ndCBqdXN0IGRyb3AgdGhlIFBoYWJyaWNhdG9y IHJldmlldyBpbnRvIHRoZSB0cmVlLi4uPC9kaXY+PGRpdj4oNSkgSXQncyBwaGFicmljYXRvcjog dGhpcyBpcyBhIGdyZWF0IHRvb2wgZm9yIGRldmVsb3BlcnMsIGJ1dCB3ZSBoYXZlIGEgdGVycmli bGUgdHJhY2sgcmVjb3JkIG9mIHVzaW5nIGl0IGZvciBpbnRha2UgZnJvbSBuZXcgY29udHJpYnV0 b3JzLiBXZSBkb24ndCBoYXZlIGFueSBvdmVyc2lnaHQgYXQgYWxsIG92ZXIgdGhpcyB0b29sLCBh dCB0aGVyZSdzIGF0IGJlc3QgdGVwaWQgYW5kIGx1a2Ugd2FybSBhdHRlbXB0cyB0byBsb29rIGZv ciBkcm9wIGJhbGxzLjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+QWxsIG9mIHRoZXNlIHRoaW5n cyBhcmUgYSB0ZXJyaWJsZSBleHBlcmllbmNlLiBJIGNhbiBvbmx5IGFwb2xvZ2l6ZS4gVGhlc2Ug ZGF5cywgd2UgbWlnaHQgc3RlZXIgdGhpcyB0b3dhcmRzIGdpdGh1YiwgYnV0IHRoZSAndmVuZG9y IGltcG9ydCcgbWVhbnMgeW91IHJlYWxseSBuZWVkIHNvbWVvbmUgb24gdGhlIGluc2lkZSwgb3Ig eW91IG5lZWQgdG8gYmUgb24gdGhlIGluc2lkZSB0byBtYWtlIHRoYXQgd29yay48L2Rpdj48ZGl2 Pjxicj48L2Rpdj48ZGl2PlNvLCBob3cgdG8gbW92ZSBmb3J3YXJkPyBXZWxsLCBJJ2QgbGlrZSB0 byBwcm9wb3NlIHRoZSBmb2xsb3dpbmc6PC9kaXY+PGRpdj4oMSkgc3VibWl0IGFsbCB0aGUgb3Ro ZXIgUGhhYnJpY2F0b3IgcmV2aWV3cyB5b3UgaGF2ZSBvcGVuICh0aGV5IGFyZSBtb3N0bHkgZ29v ZCwgb3IgY2xvc2UgdG8gZ29vZCkgdG8gZ2l0aHViLiBHaXRodWIgaXMgYmVpbmcgYWN0aXZlbHkg bWFuYWdlZCBhbmQgd2lsbCBtYWtlIGl0IGZhc3RlciB0byBnZXQgdGhpbmdzIGl0LiBJdCdzIGEg bXVjaCBiZXR0ZXIgdG9vbCBmb3IgbmV3IGNvbnRyaWJ1dG9ycyAoYW5kIGV2ZW4gZnJlcXVlbnQg Y29udHJpYnV0b3JzIG9mIHNtYWxsaXNoIHRoaW5ncykuPC9kaXY+PGRpdj4oMikgSSBzaG91bGQg ZG8gYW4gdmVuZG9yIGltcG9ydCBvZiA1LjMuMCBmcm9tIGdpdGh1YiwgYW5kIGRvIHRoZSBtZXJn ZSB0byBhIGJyYW5jaCBhbmQgcHVzaCB0aGF0IHRvIGdpdGh1Yi4gWW91IGNhbiB0aGVuIGxheWVy IG9uIHlvdXIgY2hhbmdlcyBhbmQgdGhvc2UgY2FuIGJlIHJldmlld2VkIG1vcmUgY2xvc2VseSBh cyBhIHB1bGwgcmVxdWVzdCBhZ2FpbnN0IHRoZSBicmFuY2ggSSBwdXNoLiBJIHN1c3BlY3QgdGhh dCBtb3N0IG9mIHRoZSBpc3N1ZXMgYXJlIHNvcnRlZCBvdXQgYWxyZWFkeSA8YnI+PC9kaXY+PGRp dj4oMykgSSdsbCBsYW5kIGl0IHZpYSB0aGF0IHJvdXRlLi4uPC9kaXY+PGRpdj48YnI+PC9kaXY+ PGRpdj5BbmQsIGlmIHRoZSBzdW0gb2YgdGhlIG90aGVyIHB1bGwgcmVxdWVzdHMgYW5kIHRoaXMg YXJlIGdvb2QgKGFuZCBJIHN1c3BlY3QgdGhleSB3aWxsIGJlKSwgdGhlbiB3ZSBjYW4gdGFsayBh Ym91dCBjb21taXQgYml0cyBhbmQgc3VjaC48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pkl0J3Mg ZXhwZXJpZW5jZXMgbGlrZSB0aGlzIHdoaWNoIGlzIHdoeSBJJ20gdHJ5aW5nIHRvIHN0YW5kIHVw IGdpdGh1YiBwdWxsIHJlcXVlc3RzIGFzIGEgcmVsaWFibGUgd2F5IHRvIGdldCB0aGluZ3MgYW5k IGFuZCB0aGUgYmVzdCBwbGFjZSB0byBzZW5kIHBlb3BsZS4uLiAgPGJyPjwvZGl2PjxkaXY+PGJy PjwvZGl2PjxkaXY+VGhhbmtzIGFnYWluIGZvciBwZXJzaXN0aW5nLCBhbmQgYWxzbyBmb3IgZXhw cmVzc2luZyB0aGlzIGNyaXRpY2lzbSB0aGF0IHdlIChob3BlZnVsbHkpIGNhbiB1c2UgdG8gbWFr ZSBpdCBiZXR0ZXIuPGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+V2FybmVyPGJyPjwvZGl2 PjwvZGl2PjwvZGl2Pg0KDQogICAgICAgIDwvYmxvY2txdW90ZT48L2Rpdj48ZGl2IHN0eWxlPSJm b250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsgY29sb3I6IHJn YigwLCAwLCAwKTsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyI+PGJyPjwv ZGl2PjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsgZm9udC1zaXpl OiAxNHB4OyBjb2xvcjogcmdiKDAsIDAsIDApOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAy NTUsIDI1NSk7Ij5IZWxsby48L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNh bnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsgY29sb3I6IHJnYigwLCAwLCAwKTsgYmFja2dyb3Vu ZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyI+PGJyPjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQt ZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyBjb2xvcjogcmdiKDAs IDAsIDApOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7Ij5JJ20gbm90IHRo ZSBhdXRob3Igb2YgPHNwYW4+RDQxNDIxLiBKdXN0IGFwcGxpZWQgdGhlIHBhdGNoIHRvIHRlc3Qg aXQgOCBtb250aHMgYWdvLiBBbmQgcmVjZW50bHkgZGlzY292ZXJlZCB0aGF0IGl0J3Mgc3RpbGwg bm90IGNvbW1pdHRlZC48L3NwYW4+PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFs LCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGJhY2tn cm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsiPjxzcGFuPkkgY2FuJ3QgY29weSB5b3Vy IG1lc3NhZ2UgdG8gUGhhYnJpY2F0b3IgYmVjYXVzZSBkb24ndCBoYXZlIGFuIGFjY291bnQuIDwv c3Bhbj5QbGVhc2UsIGlmIHlvdSBoYXZlIHRpbWUsIGhlbHAgdGhlIGF1dGhvciBpbiBENDE0MjEu PC9kaXY+PC9ibG9ja3F1b3RlPjxkaXY+PGJyPjwvZGl2PjxkaXY+QWggeWVzLiBJJ3ZlIGJlZW4g aW4gdG91Y2ggd2l0aCB0aGUgYXV0aG9yIGZvciBvdGhlciB0aGluZ3MsIGFuZCBzb21laG93IHRo b3VnaHQgaXQgd2FzIHlvdS4uLi4gIEknbGwgcmVhY2ggb3V0IHRvIGhpbSB2aWEgb3RoZXIgbWVh bnMuLi48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pldhcm5lcjwvZGl2PjwvZGl2PjwvZGl2Pg0K DQogICAgICAgIDwvYmxvY2txdW90ZT48YnI+DQogICAgPC9kaXY+DQogICAgICAgIDwvYmxvY2tx dW90ZT48YnI+DQogICAgPC9kaXY+PC9ibG9ja3F1b3RlPjwvZGl2Pg0KDQogICAgICAgIDwvYmxv Y2txdW90ZT48YnI+DQogICAgPC9kaXY+DQogICAgICAgIDwvYmxvY2txdW90ZT48YnI+DQogICAg PC9kaXY+PC9ibG9ja3F1b3RlPjwvZGl2Pg0KPC9ibG9ja3F1b3RlPjwvZGl2PjwvZGl2Pg0KDQog ICAgICAgIDwvYmxvY2txdW90ZT48YnI+DQogICAgPC9kaXY+PC9ibG9ja3F1b3RlPjwvZGl2Pg0K DQogICAgICAgIDwvYmxvY2txdW90ZT48YnI+DQogICAgPC9kaXY+PC9kaXY+ --b1=_JWexQ6bpLKudsw2VBuqTCOLcF6jLLhngbknHlLjCiU-- From nobody Thu Mar 27 12:57:09 2025 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 4ZNkFj0JLdz5rKtZ for ; Thu, 27 Mar 2025 12:57:13 +0000 (UTC) (envelope-from garga@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZNkFh48HCz3mPJ; Thu, 27 Mar 2025 12:57:12 +0000 (UTC) (envelope-from garga@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1743080232; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=Kaclya4AIr4p6+p1le7gqMg4J1UBWaa73y9+Iy8OzoA=; b=KLd1ZAj0xryTT10JerfWifUjfa5L8KLKhYc8ieuySThAt6JQcg0nhdwNr7AI7zCQG0IHPI 5pE6MP/5ypRCTTLxtbEA8mhhgX1bxHf5d0jU3ijFkgATs9VFA7gkJX79e2U3umVP+cL32g GFer885CWwXJvp9eI+p+dJ00/7gHurO7QW5JSYgLgv7x/V8tzeAoP4MoLSX4dmaIoz9mHy NTLiDXy6nDVfsp75viwObKE7GRdg9fUdAiET8D2AU0CiHJFZFszr0B1TqB1jA8YS4e9SVg Q8A/PgZP8gXxFg9i8tHCNwcE8Dwu1ZDFfcpWL02wLsYOwgJqs8NQMnc9sjQDDg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1743080232; a=rsa-sha256; cv=none; b=cxRqGSQQiLuJpf+iyz6UP/j1WgIBW3A4MbftaSDu0abxy5Cb3HxjgW1XJZ5mGKMGaK0b7r Hz7HH2hDoqbPdH8uV/WJV06f0LfrkiiyM0xOzHn+iDYYsHw86B4askk9xrmry6RBGIvUwy BiLE6fPFzegRZfgb8fEtregHPVcQzL09MLgItQbMeGPMhXBhnWzo4kaP4R7g6nBdQOqwme K/ZhJ0Tx45tUoR1XzaM38Dbb4hO5y5T8rrWDcR6Xz1z+J/R0wyE3H9jBX8H/1gGFSykJ20 QjvSZaifwg+RBiY/vui1HQovgv/l1dQV30iSEmRajDaetSxm/9tiJAPQDoi2UA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1743080232; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=Kaclya4AIr4p6+p1le7gqMg4J1UBWaa73y9+Iy8OzoA=; b=hJA8qtw+36tFTa84R0ZPwSxEmdvDZAm20T/ZZd+0rRKK0FLNRN3VZKomhnay5Hv8ZdeLHa 5bZTYr0eLCWZVVMefGaux8pyt2nUhr2JSc80yOmaaCNRLfg8XuduuZElT/+5ei41pXgqEJ 7vGCkYrk141rJ6uA8iP3QF6KbDaXsBFv8P+kAuagE8ALdF8+qh4nsgRFk1QYbmwDIcYbF4 vClexwzW+jlwDtm/Xa1lXqdk+dXHGBozJRFPFDoGjQHi3WHNFZIDAl90q8jVvuFZbQYc4Y CxqIme1kan4MHcelyRWUAK8tuh5xzdB3RVCCcmvpu6q0pP8GjCxzLSn+DmwCzA== Received: from [IPV6:2804:f1c:802:dd01:450e:7784:2a7b:cdda] (unknown [IPv6:2804:f1c:802:dd01:450e:7784:2a7b:cdda]) (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 did not present a certificate) (Authenticated sender: garga) by smtp.freebsd.org (Postfix) with ESMTPSA id 4ZNkFg720GzmwC; Thu, 27 Mar 2025 12:57:11 +0000 (UTC) (envelope-from garga@FreeBSD.org) Message-ID: Date: Thu, 27 Mar 2025 09:57:09 -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 Thunderbird Subject: Re: suspend/resume broken on Thinkpad x230 To: grahamperrin@gmail.com, freebsd-current@freebsd.org References: <30322e00-271d-41f7-aa76-48e5074018b2@FreeBSD.org> <88ff7cdd-60ac-41de-9b51-6b4864c31ef6@gmail.com> Content-Language: en-US From: Renato Botelho Autocrypt: addr=garga@FreeBSD.org; keydata= xsBNBGStavwBCACjNlp/9+Y+VFe9ieR2h/WWbdvjz4Mb2z/f22bGoaskzCfvVNbo/v3i34I9 H6OdgZkGqheQEAD2jNfRbmPr4z40xDMUpYGLds+1Mvg7G3Hms3j5Ef8KaLSWUNWIfwKdfSVR Qs35ccSJxAdRW5YdI6J3xZgika+3Bc4eJ05YE/nWW+PNTYevt5rqD50N3zybVYIcLoqVPpBi AZE/sf5SLiLACIJb1t/s4x+pi8vgWevxVVT9u8V1f8zYErmHSLSqjxii0B3eRZphX9NCJOv9 +tfFZhnENInhn9gT7H4e2YumUltEy3jacONHJF3CC1pvvWEa6lEyypclMOkHQwNON7DLABEB AAHNLFJlbmF0byBCb3RlbGhvIChGcmVlQlNEKSA8Z2FyZ2FARnJlZUJTRC5vcmc+wsCXBBMB CgBBAhsDBQkFo5qABQsJCAcDBRUKCQgLBRYDAgEAAh4FAheAFiEERL7Dxegbnh7xTiQ5Ob6P xxJcZXoFAmSta78CGQEACgkQOb6PxxJcZXrYlggAgaZmr6c1yIWzN8VksHrHpwt/uxONEP+h ljy3yfrMsgfS5wx5Uzgfih1xYZUFC6jiI63CetqBqJpp3g1klRS1UWYKx2NeXphDMYZEdPm/ a6sXh4bKZbk6IE8Yn0/YiRT57d9DtbvswC7Gn7Igj/MSbhl49TvTGyvuB6juaffVoYZViomx 5zMoee8Ml2o2qj3MrCJ+/K8GU54RlpOGqGRsqdwVdr9XEWub6fF2YFwR46cjmbiU3P5urFHH nkJlBGPIwKxHimTW0lZsdx9aCKRDd/D80/WOEzXmk3k8B9lv/GsvOluHmveLhJG1R1tIJ31I f2q8dfTvqsQXnu8CcWRcgc7ATQRkrWr8AQgA1DufoxScA+CWQbUR6zExIu8wXQKrhuRt4DG2 BgynT7EMUvEBadcbQRZXsBpemNfncc9Axyut/+rWiyKJf9BLQuo/9QYmSRvW1U6+0LJUYmdg kMyBeYaPk+vnssv/u9jLuvV7FVgyE0yk1iaWIKOVDD+XrQCOvGw9uSceBrQyCyo3A/eRM/+p vnDCaywR63PKE+3axk6lfNdGK3TnaWmS30/ZDCZlNsXuqprqR4JdT5wXids5o36dsuJ5EZ20 s5hNMD34s4Yr1Y1R9elH6qBsFCpozs0+jwrArxq+UJJCR6hH5W8ZEwJtRC8tzR8mRE1WywzX BXYj0YhfGztQIxZckQARAQABwsB8BBgBCgAmFiEERL7Dxegbnh7xTiQ5Ob6PxxJcZXoFAmSt avwCGwwFCQWjmoAACgkQOb6PxxJcZXr1vgf/SKXhoZcUU5I7TqcbHg0lJz9tICTupCGHWr/s SQgjh9oEM5j1wqW7FlCGP90Tl9K0g3ow9YdbhU7VK470o6pymX9V9eLHzGgkZO/KMEtGBeK1 u+5ePjCJ/MK5B21KODLSU7WrIL1VN5ceXfQPLYt02LMLtPri+oduHD6RNBeA7US1DUzleq5F 9NHGbvV2U7BdDUezpiO8NaFjFZVB11I5d99FxUM5XGVstI3VhsRKZxjY0KnqJzaQgTFsPGmv AUfZVIN1pXgXiedhPXpr8+Y64jP+pHVwpVmh1zYWL6+q3kqFOUVP6c5iiMeoEXZvgJz7x/AC ek3X5gvu8Hpcv+MZIg== In-Reply-To: <88ff7cdd-60ac-41de-9b51-6b4864c31ef6@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 26/03/25 21:17, grahamperrin@gmail.com wrote: > Which driver? > > pkg iinfo drm I tried these 3 without changes: drm-61-kmod-6.1.92.1500030_3 drm-61-kmod-6.1.128.1500034_2 drm-66-kmod-6.6.25.1500034_1.pkg > On 26/03/2025 14:01, Renato Botelho wrote: > >> … Another user reported same problem on his thinkpad x270 > > What are the graphics cards in your machine, and the other user's? > this is mine: vgapci0@pci0:0:2:0: class=0x030000 rev=0x09 hdr=0x00 vendor=0x8086 device=0x0166 subvendor=0x17aa subdevice=0x21fa vendor = 'Intel Corporation' device = '3rd Gen Core processor Graphics Controller' class = display subclass = VGA other user (thinkpad x270): vgapci0@pci0:0:2:0: class=0x030000 rev=0x02 hdr=0x00 vendor=0x8086 device=0x5916 subvendor=0x17aa subdevice=0x5062 vendor = 'Intel Corporation' device = 'HD Graphics 620' class = display subclass = VGA It's interesting to mention that I did a bisect between 91d8ee3579ef (the version other user rolled back on his system and works) and 0849f1634a70 (broken version I got here. First I did the bisect building only kernel and I ended up on 91d8ee3579ef with the problem still happening. Then I did a buildworld on this version and I'm now running it here and problem is still happening. I wondered if the problem was caused by drm port upgrade that happened together and downgraded drm to the older version I was running before upgrade, that was still present in /var/cache/pkg, and it didn't help as well. I have no idea what to do here to understand what is happening. Oh, and btw, there is now 2 more people complaining about this problem on .br Telegram group -- Renato Botelho From nobody Thu Mar 27 21:08:19 2025 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 4ZNx8d4grLz5rvPw; Thu, 27 Mar 2025 21:08:33 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZNx8c4Y5fz3wVT; Thu, 27 Mar 2025 21:08:32 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=TJIAQVON; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rick.macklem@gmail.com designates 2a00:1450:4864:20::52a as permitted sender) smtp.mailfrom=rick.macklem@gmail.com Received: by mail-ed1-x52a.google.com with SMTP id 4fb4d7f45d1cf-5ed43460d6bso2467676a12.0; Thu, 27 Mar 2025 14:08:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1743109710; x=1743714510; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=UranmtfHjBu5Ieon3zgi//rINf6snOuCaPIsZRl3jr4=; b=TJIAQVONMY4GQ1Xk1vdaU2OmeYpxxKXro9dWzfVonqxY84wzWRzs9NGBj91SAnzVgU vG5f3FSvLItvHjepEkN0rOwrpqXbq9c61Jbvkd4vAiqkP8clLXxeck7hXZKCzpocX0fD SlXWDOTJdQPopcf2uw1+W/YgA67Jbse+wjccC1JXXnUuBl9NPr8Edr+A4NCmusWjfYZ+ +4b+U3FpJ1Dz/sigMY+MH7gjlgtESgG+d0udL8y+eJIbOnIZ0Yax4cFCMkQhD+Mb8jUQ k9eqJ/WHEWojca+QxaIrdJT+JJ9ZGS6Zk8oq9DQQkFA7rytmzZ1RAQmpABGuhqKy0i1Y JLEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743109710; x=1743714510; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=UranmtfHjBu5Ieon3zgi//rINf6snOuCaPIsZRl3jr4=; b=kTW2xJFxaAq8pE1kpEifQy44RRMN78UjSCeEuZ/cbwgUTNmUL+qmsZeDUEe0W2FyAk VumIrFpkwbjM6ruFhp8klWRSQ3mw8/2wVzWtaH0rGFjOmG8KTmQG7kxboZquERn8H/bI 0V/ww/CXKVA27OpJPm5208gD8V0v/eACc9DhX5Z1Xo9AVUiD3aEqq4AZlhI5J+bXCQ9/ tNE0D2hyJDloS5C73R+lSW7cIME3Bw+7FPIOC+cbRT9bUSsfjR4c8RThgu8p2t9UuB2c 2zdDjpjCQaUDSAZH4M9otSFGodwld9EP1QAXjcU3vLE6IZzrfqxi5cZi04sJ4cJ/NOTY CKig== X-Forwarded-Encrypted: i=1; AJvYcCU1VLZBm83Qvt9IQoCoIxiyNs+6ix0y/YfklI6kkSt6bMlZzsN27ZFB46coqTAg6IfeL5uQPhNXjHkujvyze7YV@freebsd.org, AJvYcCVRRS0xLna0BPo9o1qP6RZYyTKKCNWUNwJIKOAv6/ExpqJ8uzf7DLgZYUelYohi0ClHofTjax6lj38rMj4=@freebsd.org, AJvYcCW6v2jOnsNUrtbiGI5IBPnB+qt9J4tZkMsc7LBGdnjY0Mkd9rvScA5WUh2bIGzR9kFyZzeL@freebsd.org X-Gm-Message-State: AOJu0YzPAcE1QtxFgxOEroNQLeqZth2ediFMxCiT9b9PK7uY8WXfMaE4 9lplj8M52/X4syrk2irjxUaa/U3sv7x4JDyOb2Uq39wymT19SqQ95yADmGYLvTne6KJYDZIXinN m2XDyir8i/emcNSuS4EzCBezXMA== X-Gm-Gg: ASbGnctWJ2tMlFbRKP1MASbp/lRpQzDMj6+QuDqWX6JfaICx77uH3vPU8tjVTI5UNXl A/bxVpyBoe2W/cAt/EoLTBG3cUkJhXnsJGBg+Utgb4irJoyogJSHfVwggpHj3rivU/jxq4snhf+ Mwnd34ypskgVNPAVZrz6VEvj1OxBP8q6lI2F2HWbWD+mMj7JUusY1akn8zUw== X-Google-Smtp-Source: AGHT+IFSn7qlLRNDjOYx5jEZ+2fs9oXhlmKiCFGb0+YZOzs4QllcIQOKfsxHtchYwlNykZ3UQjHnNhf9VXzXucU4Eo4= X-Received: by 2002:a05:6402:1d4a:b0:5ec:c976:268a with SMTP id 4fb4d7f45d1cf-5ed8e4a9544mr5465356a12.15.1743109709961; Thu, 27 Mar 2025 14:08:29 -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: In-Reply-To: From: Rick Macklem Date: Thu, 27 Mar 2025 14:08:19 -0700 X-Gm-Features: AQ5f1JqoK57YHh8tQnLRuGCaNJ9wazKBEBdfIjRX6VqcUkd6gktSjUi2uHnXM4o Message-ID: Subject: Re: RFC: Solaris style extended attributes for FreeBSD To: Lionel Cons Cc: Andrew Walker , Konstantin Belousov , freebsd-arch@freebsd.org, FreeBSD CURRENT , Cedric Blancher Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Result: default: False [-2.48 / 15.00]; SUSPICIOUS_RECIPS(1.50)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.998]; NEURAL_HAM_SHORT(-0.98)[-0.977]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; TO_DN_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::52a:from]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; FREEMAIL_FROM(0.00)[gmail.com]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_FIVE(0.00)[6]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_CC(0.00)[ixsystems.com,freebsd.org,gmail.com]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org,freebsd-current@freebsd.org]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TAGGED_RCPT(0.00)[]; MISSING_XM_UA(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; FREEMAIL_ENVFROM(0.00)[gmail.com] X-Rspamd-Queue-Id: 4ZNx8c4Y5fz3wVT X-Spamd-Bar: -- On Thu, Mar 27, 2025 at 11:23=E2=80=AFAM Lionel Cons wrote: > > On Thu, 27 Mar 2025 at 03:28, Rick Macklem wrote= : > > > > On Wed, Mar 26, 2025 at 5:36=E2=80=AFPM Andrew Walker wrote: > > > > > > On Wed, Mar 26, 2025 at 5:05=E2=80=AFPM Rick Macklem wrote: > > > > I am now less convinced that a new value for xattr is needed. > > > > I need to do more testing, but with xattr set to dir and not sa > > > > (shown as "on" for zfs get xattr), the attributes seem compatible > > > > and it is just the KAPI which changes. > > > > > > > > rick > > > > > > Rick, is it OK to serve the same information as an xattr and as a > > > named attribute over NFS? > > Good question. I don't have the answer. It seems that it "will work", > > so so long as the "system attrnamespace" attributes cannot be accessed/= created > > on the named attribute side, I don't se an obvious problem (see below). > > No, this is not intended to work that way. > > SUN plans with CITI's Windows driver was to implement Windows EA > (Extended Attributes) as "named attributes" (ref: > https://datatracker.ietf.org/doc/html/rfc5661#section-5.3) with a > prefix, e.g. EA attribute "abc" will have the ZFS/UFS/NFSv4 named > attribute named "windows.ea.abc". > Windows streams would also be prefixed, e.g. Windows stream "mystream" > would go into the name attribute "windows.stream.mystream". Well, right now ZFS has a function called zfs_check_attrname() to check for imbedded '/' characters and prefixes not allowed. The current list of prefixes is: "freebsd:" - Used by FreeBSD for system attrnamespace attributes "security." - Linux related, I think? "system." - Linux related? "trusted." - Linux related? "user." - Linux related? So, except for the last one, the restricted prefixes are ones that are used by the associated system for privileged attributes. (The last one "user." is a Linux-ism that can optionally be prefixed to all names, but that seems to be disabled by default.) Note that RFC8276 specifies "user" attributes, so the above mostly applies to attributes set locally in ZFS by Linux or FreeBSD. Note also that the prefixes you are suggesting would currently be allowed. > > Prefixing is important to avoid namespace collisions. For example > Solaris has the "SUNWattr_" prefix for their internal stuff. IANA > created a registry called the "NFSv4 Named Attribute Definitions > Registry" to register these prefixes. Since only Solaris has implemented named attributes as far as I know, I suspect this IANA registry is largely forgotten. RFC5661 notes that there is no initial registry. I just looked and there does not appear to be any prefixes registered. > > Finally, Linux xattr and Windows EA are size-limited, Windows streams > and NFSv4 named attributes have unlimited size, and can even be sparse > (Google SEEK_HOLE about that). > > So if someone wants to implement Linux XATTR, then do it as SUN > intended, and create a "linux.xattr." prefix. Well, as I noted above, that is not what the Linux ZFS port does and I am not going to try and tell them it needs to change.;-) > > Lionel From nobody Fri Mar 28 14:12:23 2025 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 4ZPMtJ4LM5z5rvCT; Fri, 28 Mar 2025 14:12:40 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZPMtH56xzz3mPK; Fri, 28 Mar 2025 14:12:39 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=TvFQSaCa; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rick.macklem@gmail.com designates 2a00:1450:4864:20::535 as permitted sender) smtp.mailfrom=rick.macklem@gmail.com Received: by mail-ed1-x535.google.com with SMTP id 4fb4d7f45d1cf-5e61da95244so4076490a12.2; Fri, 28 Mar 2025 07:12:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1743171156; x=1743775956; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=PdEedoBh+nEFBoUNt2d6Q6DrXZyS9UP7Jb1X+jbFOcA=; b=TvFQSaCaIUttE8h9qWhvKCWmMm1iKlErjcahJB5cCuYXz9EWSfbUSW9WtHI34jQiZO /jr06J8r8CFan8bx76ytQdBmw4crkftteLsY2Gd9aPug6MiYhhH08zUl5jlD7ozT5pYo GMqhgQbfRzgTTPBdkEkqYaJrtoamvQAWeLEdS9x8PQk3hTGxLSI1fievVUtFxRtrjAdt EWrwT8WgFyNs1pFrg89clM5HWkNV4/g90ajFWGt/vepm9pGBI8yn4ejznWjxFF87aGxs WnjgVBefaRSdNOFTgZPbo9dTcRbeFIu1R2ZN7n3iDb9gzLtl4icGmIyjrd5yw2WudYyJ voZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743171156; x=1743775956; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=PdEedoBh+nEFBoUNt2d6Q6DrXZyS9UP7Jb1X+jbFOcA=; b=n4PnxmwSX2LVPmeg7eWJ7gJ+ssR5hPCHTUrr+SyjndbgRIhy265skDtZr2tsGkZ0zV 6ygFb2L/d4jBv9OvVaonM1VsMrC+UcK3z+ZgANFZDDC5AaIAKDuAhMIF90612xvl79VX rfDbwBZOhgbmxkb7jUH6KHpggQln/69Bwfj116aH8bo6eh3gKr+2wV5g8lCPbmrzJ9fQ YK2uf5cahsgko9tprfcCDAPRIFwP9we+d7wxm3JutKaSYIBxWD9H6dCrGArvAbCcCbKJ aGEuhyU+pGjv1GUQzObP0CSmHFiugJak2AkdBBsBfCQhEp+hGrvoEy14+anykTh+uWjZ d/Uw== X-Forwarded-Encrypted: i=1; AJvYcCWenlBVK0WtKTkVuVBfvvJLgib47f2RODsFOPCQ/RC8OYb4VvanPvDKgb+HZCyb2SwatOeVPbotNYnOo90=@freebsd.org, AJvYcCX4HYAkjHO//4mAzgnfVvXzoHdeeR1nOdez6qneUuHBjLxzwpLxiMDyG3Yk3wE6Kk8aT5jcWQSrZQaScmdlzgdt@freebsd.org, AJvYcCXGsLk7MHpZ3uCS48/QQfzFkQkL7cs4Bgt3KKbhBDWfubp1z/ATdDhDDmpQkSonLkSYU6w3@freebsd.org X-Gm-Message-State: AOJu0Yz/yFh9RseAdl62Pgx6XIIL5p1VSIcqF7EERRL5IKr3K26ad6ER JXUvnkh3ZEbp+wjCj1uTfvx/S0Bd+/ZmQHC7Al81Il5Erw75CmvmKM21EX9ju63w+TsDZKj8fB4 ZuoElk8iYBui/EZ+PH0F9oHIGyg== X-Gm-Gg: ASbGncuyvPeJgcmyzydj3CrP/EGlsKq4n7v0feCvv+nUqfFxi7ZMe8A7mwvA1P7Uaa3 U1f6X/gOxGi0/+t4F1uYXzqGBlWmh99U9GT/dtNOEb/U+24hTiyB/kIxPcLvNIExBjNLEcfmuxd 37TlNXRY0XxtvskBaEY41fQIKnW3TEueoiSyg/YJUFxuG/+g3Z/PHMyamSYWfhNZOJ9yHj X-Google-Smtp-Source: AGHT+IGrNW3LnHYx7g56LfYK/SSp281W6IRH5ByiUpH7z7+LV0FnbbLGdof0M6s6/8/3jLml64I3aurbHSkG16Fqfpw= X-Received: by 2002:a05:6402:524e:b0:5ed:1262:c607 with SMTP id 4fb4d7f45d1cf-5ed8f907b65mr6745385a12.31.1743171155579; Fri, 28 Mar 2025 07:12:35 -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: In-Reply-To: From: Rick Macklem Date: Fri, 28 Mar 2025 07:12:23 -0700 X-Gm-Features: AQ5f1JoHvP3As0nAGKj8KNJG3b3DIYhItbcP0Fitw46EfAtSojTBCwlHrP9VF_U Message-ID: Subject: Re: RFC: Solaris style extended attributes for FreeBSD To: Lionel Cons Cc: Andrew Walker , Konstantin Belousov , freebsd-arch@freebsd.org, FreeBSD CURRENT , Cedric Blancher Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Result: default: False [-2.49 / 15.00]; SUSPICIOUS_RECIPS(1.50)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.997]; NEURAL_HAM_SHORT(-0.99)[-0.993]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; TO_DN_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::535:from]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; FREEMAIL_FROM(0.00)[gmail.com]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_FIVE(0.00)[6]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_CC(0.00)[ixsystems.com,freebsd.org,gmail.com]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org,freebsd-current@freebsd.org]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TAGGED_RCPT(0.00)[]; MISSING_XM_UA(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; FREEMAIL_ENVFROM(0.00)[gmail.com] X-Rspamd-Queue-Id: 4ZPMtH56xzz3mPK X-Spamd-Bar: -- On Thu, Mar 27, 2025 at 11:52=E2=80=AFAM Lionel Cons wrote: > > On Thu, 27 Mar 2025 at 19:31, Lionel Cons wrot= e: > > > > On Tue, 25 Mar 2025 at 20:06, Lionel Cons wr= ote: > > > > > > On Sat, 22 Mar 2025 at 21:34, Rick Macklem w= rote: > > > > > > > > On Sun, Mar 9, 2025 at 5:38=E2=80=AFAM Andrew Walker wrote: > > > > > > > > > > > Since ZFS is already wired for them, adding the basics is prett= y > > > > > > straightforward. I am not suggesting that they should replace t= he > > > > > > current FreeBSD extended attributes > > > > > > > > > > The ZFS story is more complicated. When ZFS is configured with > > > > > `xattr=3Dsa`, xattrs are preferentially written into system attri= butes > > > > > (SA). This was introduced IIRC primarily for performance reasons > > > > > This allows tiny xattrs (~100 bytes) to be stored with the dnode = and > > > > > up to 64 KiB of xattrs to be stored in the dnode spill block. If > > > > > additional space is needed then they are written using the older-= style > > > > > file-backed approach. > > > > > > > > > > What this means is that if someone is using this relatively commo= n > > > > > configuration (the default in TrueNAS and in many Linux distros),= then > > > > > the result would be that only some xattrs written via extattr wou= ld be > > > > > visible by directly opening the ZFS attr dir. It would also intro= duce > > > > > a mechanism whereby an xattr with the same name is written to two > > > > > different ZFS locations, which would potentially cause you to see > > > > > different xattr data depending on whether you read it from extatt= r or > > > > > via the attr dir. I don't know off-hand whether this could lead t= o > > > > > corruption / unexpected behavior in ZFS but if you haven't looked= into > > > > > it yet you may want to make sure you're properly handling the cas= e > > > > > where someone has already written SA-backed xattrs. > > > > I am in the process of defining a new setting for the xattr propert= y > > > > I've called "named" which would need to be set for the Solaris styl= e > > > > extended attributes to work. > > > > > > > > I am making progress on the patch and am currently working through > > > > permissions (or authorization if you prefer). > > > > > > > > Here is what OpenZFS appears to do currently. > > > > I am wondering if these sound reasonable for these attributes? > > > > > > > > - When an attr directory is created for a file object, the ownershi= p > > > > (uid and gid) is set to the same value as the file object. > > > > The mode is set to 041777 (a directory with sticky bit set and > > > > permissions for everyone. (It ignores the "mode" argument to > > > > the open.) > > > > --> As such, anyone who has access to the file object can access > > > > the extended attribute directory. > > > > > > Yes, that is the expected behaviour > > > > > > > > > > > - When an attribute is created in the attribute directory, the uid = is > > > > set to that of the creating process (cr_uid), the gid is set to = that > > > > of the directory (which is also the gid of the file object). > > > > The mode is set to that of a regular file with low order mode bi= ts > > > > as specified by the "mode" argument to the openat() that create= d > > > > it. > > > > The mode can be changed with fchmod(2). > > > > --> As such, access to each attribute file is controlled by the > > > > attribute file's creator. > > > > > > > > Any comments on the above? > > > > > > Yes, that would be the expected behaviour. > > > > > > > > > > > A couple of other questions... > > > > - Should subdirectories of the attribute directory be supported? > > > > I currently do not allow this, but it appears to be supportable > > > > by both OpenZFS and NFSv4. > > > > > > No, please no subdirs for now. As far as I can see all consumes of > > > such an API (Windows, MacOS etc) use flat layouts for the attribute > > > and alternate data streams virtual dirs > > > > YFI Roland Mainz pointed out that > > https://datatracker.ietf.org/doc/html/rfc5661#section-5.3 page 106 > > describes an attribute directory limits. I have lived with this RFC for quite a few years. Yes, in the section he has quoted it states that subdirectories cannot be created. Then elsewhere (I'm not going to search for it now) it talks about handling of subdirectories of the named attribute directory. (I suppose "not being able to create them" is not the same as "handling them, if they already exist".) I have gone with "no subdirectories allowed" in the patch, as suggested by Lionel. > > > > Lionel > > Is there a freebsd mailinglist with minimum other traffic where this > kind of debate&planning can be done? There is no mailing list specific to NFS for FreeBSD. Also, "low noise" implies people that need to see the discussion do not see it. (I don't find freebsd-current@ too noisy and freebsd-arch@ is read by few. I included it here, since it is technically the correct place for "new feature" discussions.) rick > > Lionel From nobody Fri Mar 28 14:17:41 2025 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 4ZPN0P2Z1Cz5rvTY; Fri, 28 Mar 2025 14:17:57 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZPN0N3Jcjz3qWV; Fri, 28 Mar 2025 14:17:56 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b="ND4Gawn/"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rick.macklem@gmail.com designates 2a00:1450:4864:20::536 as permitted sender) smtp.mailfrom=rick.macklem@gmail.com Received: by mail-ed1-x536.google.com with SMTP id 4fb4d7f45d1cf-5e5bc066283so3554382a12.0; Fri, 28 Mar 2025 07:17:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1743171475; x=1743776275; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=afIx0kqh+/gVCGcYyJEN7RuZh/RhuEP9rnFgs10C+RI=; b=ND4Gawn/kxvFQvx9hYGs32jCEMhP1s611jQSBmHdVrj3cOCCvZ1gMQ01DBLp+NzPGg p5+H4zxHUa24t+J5HpB6fPbC2wpfl4oi4sHoNST+wfi7soEvjiNiWsOkENm4/o1zl1bf tVJ0QJNAJpqpPccZtc+L6ov2l5K+Fub7apo4v5Zi2IgtqvnGGaxeY2taITAwQBI0L3+C O/bLEFw6IobXUnOsd5PjhWmo8scivCQnUQxU85bYZFT8U4lPL6Gawbw/sA02dAihy/jT V7CcQ76hMM2Z+o0CxgXNpXZCRMoe/u6JzLc4u7ZmXIgsyBaG2YDBk/2ob7On3kfJe8Iv KTOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743171475; x=1743776275; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=afIx0kqh+/gVCGcYyJEN7RuZh/RhuEP9rnFgs10C+RI=; b=s0HhoNaJgL0OzzHI21ZIDnmVg23sJHPJJZqXbsyi67e+CTnq5EcKAawSa/ZGe88kQU GvP/kn2AwlvWOmVxDq41yyuUrtUpqK62Ei/H0KNL9OYsZcsGbBYbM0skSOqbNNtmfHG0 0NVvHLc9yuTBhvu/SQWLdx9+k7U9Cvh3el6Xt1o3IRDGSl9GpvP4g8I/ioItiNcjAdvA hEsojfDw360B8xWzWRm4uZ7kPOPfDmC4cDcpavTf7OoO5p22Laq12aJPCOXl/YJKmcfd dM0BZLE4rg9h2cCCrNiXj9+gifWyNH8giUAho5BGHF1JlztaHwvQ5u9SEWhUKsVhWVqr Ld8Q== X-Forwarded-Encrypted: i=1; AJvYcCV5o7MQK/tyTdOtYBF3h6r2OmN4GzVT7+V09uGO3agJdtEy6+TuwECvM8jiunvLWvISI6sa@freebsd.org, AJvYcCV8HOKAG7/noF3UFpquFoE3f5eedX9S7gh/0g1j4Rl+YDGP4oNTa3z4/D0/e6GMgOSBirmYbZ64Q59olPg=@freebsd.org, AJvYcCXtuNy/TsL6q8seVULqjzYbIjXVV4GD2sEVunxSaLsOjZyXMG5XiFURbVpalCpeeKqxemyDiq9aV9qpsJi6OnOY@freebsd.org X-Gm-Message-State: AOJu0YwrsYkI4CwyTBx//QqWNJoB/tyf0wdF+SrVwNvOSlLAwCC9EjFO o4ftsAwDw6fZu8ykNGZQOyH9rKyADDgnjuS97i6PEFMK8ab94JV/fEGRPrYXKO2+9fxJ4j5tARw NMlaW6NpP6NP7iOuYVtFANHyfv6Oi X-Gm-Gg: ASbGncuootIm0HH68Oe6PwJa64f4HB2b6jYIi0UumM+6fzwfGuFJ7AsXjKak4SRUqpi xl9fL5BRwr/qxkwAXnfnqLSgbbbVQhkBQZaKlPusSwytqqY8cRQplIDWu9QKXCws/CPHZMlpR5m abCkKW9CeNIAkQVoXgu0BYznf/IVVOpJ0/iVa3n71va6HDAgY/Tud9kT4PHQ/2QhQ8uSJc X-Google-Smtp-Source: AGHT+IHZZT0k0zi+XfaUfdQ1KMMHFL3dXNAPa1+NrmgW/KIvF2OaY1xgTwNNN8VaTCHr434zqkpH07w+P4rHNA61P9w= X-Received: by 2002:a05:6402:4410:b0:5e5:e396:3f9a with SMTP id 4fb4d7f45d1cf-5ed8f113d32mr8003133a12.31.1743171474490; Fri, 28 Mar 2025 07:17:54 -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: In-Reply-To: From: Rick Macklem Date: Fri, 28 Mar 2025 07:17:41 -0700 X-Gm-Features: AQ5f1Jr-030idEd6Txy5V5L3LcxamcWfas2l29uqOQKfXnK9j5Cmukfoyq8oSXo Message-ID: Subject: Re: RFC: Solaris style extended attributes for FreeBSD To: Alexander Motin Cc: Lionel Cons , Andrew Walker , Konstantin Belousov , freebsd-arch@freebsd.org, FreeBSD CURRENT , Cedric Blancher Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Result: default: False [-2.37 / 15.00]; SUSPICIOUS_RECIPS(1.50)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.986]; NEURAL_HAM_LONG(-0.98)[-0.982]; NEURAL_HAM_SHORT(-0.91)[-0.905]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[text/plain]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_TLS_LAST(0.00)[]; TO_DN_SOME(0.00)[]; ARC_NA(0.00)[]; FREEMAIL_CC(0.00)[gmail.com,ixsystems.com,freebsd.org]; MIME_TRACE(0.00)[0:+]; FROM_HAS_DN(0.00)[]; MISSING_XM_UA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org,freebsd-current@freebsd.org]; TAGGED_RCPT(0.00)[]; RCPT_COUNT_SEVEN(0.00)[7]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::536:from] X-Rspamd-Queue-Id: 4ZPN0N3Jcjz3qWV X-Spamd-Bar: -- On Wed, Mar 26, 2025 at 11:36=E2=80=AFAM Alexander Motin = wrote: > > Hi Rick, > > On 25.03.2025 16:53, Rick Macklem wrote: > > 3 - A lot of the changes need to go into OpenZFS and I have no idea wha= t > > their position will be? (Most of the changes are in the os/freebs= d/zfs > > source subtree, which may make it easier?) > > I haven't looked on the patches yet, and I may not speak for the whole > OpenZFS project, but I'd put emphasis on a cross-OS compatibility of the > implementation, including the properties, namespace prefixes for > different APIs, etc. > > Since the directory-style attributes are growing from Solaris, it would > be nice if whatever API and on-disk format chosen would be compatible > with it. Even though the merge traffic with Illumos is not that big > lately and they are formally not a part of OpenZFS, but would be nice to > not break the ties if possible. It might require some code archeology > to understand the evolution of compatibility issues we have now. > > FreeBSD and Linux are equally important targets in OpenZFS now, and > while some things might be difficult to implement on all platforms, for > example Linux kernel does not support NFSv4-style ACLs, whatever design > chosen should allow such perspective, even if not implemented > immediately. So I am a little worried about "Most of the changes are in > the os/freebsd/zfs source subtree". We don't want it to get implemented > differently in Linux one day and become impossible to move pools between > OS'es. We already have issues there, so would be good to not grow them. > > While formally not a part of OpenZFS tree (yet?), there are forks for > Windows and MacOS. It would be cool to understand at least basic > requirements of those systems. All I've found out w.r.t. Mac OSX is that their NFSv4 client can use named attributes (with a specific mount option setting). Unfortunately I don't have a Mac. I am going to try and install Solaris in a bhyve instance. Oracle does allow freebie Solaris licenses for educational purposes, but I'm not sure if I can figure out how to install it in bhyve? Thanks everyone for comments sofar and don't hesitate to comment further. The comments have been useful, rick > > Don't get me wrong. I'd be really happy to see it done at least from > the perspective of its being implemented for Solaris decades ago, and > considering limitations other systems including FreeBSD have. It just > might be a bit tangled after the years. > > -- > Alexander Motin From nobody Fri Mar 28 14:50:47 2025 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 4ZPNkM4Xztz5rxX0; Fri, 28 Mar 2025 14:50:51 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-yw1-x1136.google.com (mail-yw1-x1136.google.com [IPv6:2607:f8b0:4864:20::1136]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZPNkL3TKFz44PN; Fri, 28 Mar 2025 14:50:50 +0000 (UTC) (envelope-from mavbsd@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b="FyfscX/l"; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=freebsd.org (policy=none); spf=pass (mx1.freebsd.org: domain of mavbsd@gmail.com designates 2607:f8b0:4864:20::1136 as permitted sender) smtp.mailfrom=mavbsd@gmail.com Received: by mail-yw1-x1136.google.com with SMTP id 00721157ae682-6ff27ad48beso22441967b3.0; Fri, 28 Mar 2025 07:50:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1743173449; x=1743778249; darn=freebsd.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date:message-id:reply-to; bh=lxcIjOm7678fpm3CIx+bRq7nsaVbmZ1m6LiQLJpRx/A=; b=FyfscX/lsP2pGu+mwzqQIy9KNCGLz116uhhvZWo1/MfPFQNP555X6gltzE0Fz6763C gKYZCdE5f9pgEJV9Ak79FZlKx6BkiZhbF0433dlKloW4b7q+wJK1oAOixRXFHFlUs7pP oAAnM9TIdVsyWoUEby08Za6nznlJxNSDG6DRfvmyYzqt7SMYCOJCdSv6C8CEEuFZu1XC Eddz+RLmEwUz/hgd7XTGfHFzsdlaWnMGzdeqLh19PXlcCqvaWnvpdp4l9jkywptB8/2g krCXZA3sxcO/MfB36Sn5y23RDOBxCn2Tx8IFaZ3IxEL8Y0rbJq/ZHrG/np8QqFJpPus9 A2fA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743173449; x=1743778249; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=lxcIjOm7678fpm3CIx+bRq7nsaVbmZ1m6LiQLJpRx/A=; b=wBYypFz3G42L9Lo5VwqIqbxJPe7Ywlrdh/ohfKk9hfYSVCRqxm/6Z8SdBeVQJ5dLgJ q7mrs0EHvexY61JyQ8bkR71YNIfircBpXy1o2/aaebq0G7y60r9zeZF7v5OQfimKGokN LKC8JfiBl7BCBiBvgjR9cfkJbOuF+l1Uauv85LLQmi0U1QujdUJY7geYjqsCtLvBSw9V VvwfLaWUZ0uPuYtQQQeU3tZNOJZzNXix7IpW9ar5XauEWP4xZttouQQw4lC79soFiBtk BjiSsdNLwEJeUwY/0Stps5YQgHssAvzk0kbASlnpyPNynQ4NyYHXLi8L8izPNaLLa/cI BCSw== X-Forwarded-Encrypted: i=1; AJvYcCWHyOWadY3Yt0S3pLgUPmdCcBdyIpVwDtxzvaXvlqbm5wP7t/o90eWVtOo0Bfh7KUGgdZzmeesLUwGhnr4=@freebsd.org, AJvYcCWNgPIobl/niXmF4kgdpfFQmquaEPcW8TiZhBgeoI5jds2DG7XmPyp8QuBT68cwTgGj/a0K@freebsd.org, AJvYcCWvfqTVMzUuKTlZ+XzoHUJthZW/52bek58/SoTNh1cEymZkK06wH5p9gV4k9I1cyyquulY9C/7f1fqbDiwY6VVH@freebsd.org X-Gm-Message-State: AOJu0YylXtVlcKA/e1AtHA9OwZQc22Y3P1xiBN3GX6bewDoSCRwM+NjL CFoEI7cjfTwHACTv/qTBspv7SM8EDz/dQiDJOya3riyuhHbj5vGLS349rw== X-Gm-Gg: ASbGncvjK7QVHeAmlTHCahpfkXy7ybg7Ugqy6hAtqPL5UD8n0oqavKd/XuLkbBtD7q2 xmMf7mlWKXLfo8uvAXtywZ/xp1eD9/+GrRSzW5IbmWazv39rJLHU2fZ0/kV+kppKu/pIzYGIel+ 9nPq2a8pixxQ0RklO/bTxRLC4v/Pzb/mk/VVOQiUOQ3eay+N1Wzj13dW36TadPcvTPwi+aRohWD Xe7dHlx8sbmXNVdaA9fiCVVQYQi493lchhWfepgwSwVLHY/9ya6KFRXHd/RVyX7QUBp4oZiLKSq jLr/Wwp30MC/KWbNDHdvoaGLTlSWyglNeQ== X-Google-Smtp-Source: AGHT+IF/4IWU09+CYfxkVQ15yuKWOYbpmD5DkVAYUx8ao3CZtMbIeGMdyVYYvhOx+zvRMPWWEL0SNw== X-Received: by 2002:a05:690c:252:b0:702:386e:2a56 with SMTP id 00721157ae682-702386e39ccmr43861447b3.23.1743173449143; Fri, 28 Mar 2025 07:50:49 -0700 (PDT) Received: from [10.230.45.5] ([38.32.73.2]) by smtp.gmail.com with ESMTPSA id 00721157ae682-7023a98a230sm7355027b3.73.2025.03.28.07.50.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 28 Mar 2025 07:50:48 -0700 (PDT) Message-ID: <05d472b9-78fd-49f0-b37c-134f63f6eca2@FreeBSD.org> Date: Fri, 28 Mar 2025 10:50:47 -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 Thunderbird Subject: Re: RFC: Solaris style extended attributes for FreeBSD To: Rick Macklem Cc: Lionel Cons , Andrew Walker , Konstantin Belousov , freebsd-arch@freebsd.org, FreeBSD CURRENT , Cedric Blancher References: Content-Language: en-US From: Alexander Motin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Result: default: False [-1.60 / 15.00]; NEURAL_HAM_MEDIUM(-0.98)[-0.983]; NEURAL_HAM_LONG(-0.58)[-0.584]; FORGED_SENDER(0.30)[mav@FreeBSD.org,mavbsd@gmail.com]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.10)[text/plain]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : SPF not aligned (relaxed), DKIM not aligned (relaxed),none]; NEURAL_SPAM_SHORT(0.07)[0.066]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FREEMAIL_TO(0.00)[gmail.com]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_CC(0.00)[gmail.com,ixsystems.com,freebsd.org]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_NEQ_ENVFROM(0.00)[mav@FreeBSD.org,mavbsd@gmail.com]; DKIM_TRACE(0.00)[gmail.com:+]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org,freebsd-current@freebsd.org]; RCPT_COUNT_SEVEN(0.00)[7]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TAGGED_RCPT(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::1136:from] X-Rspamd-Queue-Id: 4ZPNkL3TKFz44PN X-Spamd-Bar: - On 28.03.2025 10:17, Rick Macklem wrote: > I am going to try and install Solaris in a bhyve instance. Oracle does > allow freebie Solaris licenses for educational purposes, but I'm not > sure if I can figure out how to install it in bhyve? I saw you previously said that you would not really like to dig into Illumos code, but I exactly thought about it as a source of ideas about original Solaris attributes. I am regularly going there myself when I need to understand some pre-ZoL concepts. I've never had Illumos or Solaris installed though. -- Alexander Motin From nobody Fri Mar 28 20:31:02 2025 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 4ZPXH473dyz5rP85 for ; Fri, 28 Mar 2025 20:31:12 +0000 (UTC) (envelope-from dclarke@blastwave.org) Received: from mail.oetec.com (mail.oetec.com [108.160.241.186]) (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 ECDSA (prime256v1) client-digest SHA256) (Client CN "mail.oetec.com", Issuer "E5" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZPXH40GnZz3Bm2 for ; Fri, 28 Mar 2025 20:31:11 +0000 (UTC) (envelope-from dclarke@blastwave.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=blastwave.org header.s=default header.b=jY9GcWM+; dmarc=pass (policy=quarantine) header.from=blastwave.org; spf=pass (mx1.freebsd.org: domain of dclarke@blastwave.org designates 108.160.241.186 as permitted sender) smtp.mailfrom=dclarke@blastwave.org Received: from [172.16.35.3] (pool-99-253-118-250.cpe.net.cable.rogers.com [99.253.118.250]) (authenticated bits=0) by mail.oetec.com (8.17.1/8.17.1) with ESMTPSA id 52SKV2sP079446 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Fri, 28 Mar 2025 16:31:04 -0400 (EDT) (envelope-from dclarke@blastwave.org) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=blastwave.org; s=default; t=1743193864; bh=Zng+mlpgjJPhY9FtyYL4RVKZ2R8t5hez56C7SkUjpRw=; h=Date:Subject:To:References:From:In-Reply-To; b=jY9GcWM+BJTSwn2GaU7cT9Qa45G3OSfjEqWNtSire7O46cU0wWSTm5VSmvLRaoUap 5dokB+zE01MbuBQTe5MU4MfqUVmFlx8v4SQoElOdpZOI4DLsEjYHd5+lD/7x7ErM+G YAF4Lxh5ZPjAe66RM5g8okf8hGBAKQLx+MCCH0Z0oldwGt1qt/4hIZGyGEv40ymlWW SdKRjdhvWp9j2SE5DFEc3xgYNRcCVEWJxDysAsMRwFOF6EGovn9UeaVcPQI7HXr3Fa gZyTaJNDxnTJT5rShhbip2HXwSO4ukyxV6nkkYVS+676mmNZGdEqnHPNuxBugiHTbt HLF/gwramIOoA== Message-ID: <410014e4-75a6-4923-8f84-3935cab41c31@blastwave.org> Date: Fri, 28 Mar 2025 16:31:02 -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 Thunderbird Subject: Re: RFC: Solaris style extended attributes for FreeBSD Content-Language: en-CA To: freebsd-current@freebsd.org References: From: Dennis Clarke Organization: GENUNIX In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-oetec-MailScanner-Information: Please contact the ISP for more information X-oetec-MailScanner-ID: 52SKV2sP079446 X-oetec-MailScanner: Found to be clean X-oetec-MailScanner-From: dclarke@blastwave.org X-Spam-Status: No X-Spamd-Result: default: False [-4.55 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-0.99)[-0.988]; NEURAL_HAM_SHORT(-0.87)[-0.866]; DMARC_POLICY_ALLOW(-0.50)[blastwave.org,quarantine]; RCVD_DKIM_ARC_DNSWL_MED(-0.50)[]; R_DKIM_ALLOW(-0.20)[blastwave.org:s=default]; R_SPF_ALLOW(-0.20)[+mx]; RCVD_IN_DNSWL_MED(-0.20)[108.160.241.186:from]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:812, ipnet:108.160.240.0/20, country:CA]; HAS_ORG_HEADER(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_TLS_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[blastwave.org:+] X-Rspamd-Queue-Id: 4ZPXH40GnZz3Bm2 X-Spamd-Bar: ---- On 3/8/25 18:02, Rick Macklem wrote: > First off, I cross posted because I don't think many read freebsd-arch@. > There seems to be a nice market for Solaris style extended attributes. Hold on a moment. I have been following this discussion now for a while and I am trying to figure who wants this? Why? Is this a "make work" project wherein a pile of code and testing will needed? Where the word "pile" may mean years. > Since ZFS is already wired for them, adding the basics is pretty > straightforward. I am not suggesting that they should replace the > current FreeBSD extended attributes. > Well if you decide to go into NFS with xattr then you may as well dig into UFS with xattr also. Perhaps that would be insane however once you deal with ACL handling in tools like tar and ls then you will need to ponder UFS also. That means output similar to Solaris /usr/xpg4/bin/ls like so : The following example shows how to display compact ACL information on a ZFS directory. % ls -dV test.dir drwxr-xr-x 2 marks staff 2 Mar 14 10:17 test.dir owner@:--------------:------:deny owner@:rwxp---A-W-Co-:------:allow group@:-w-p----------:------:deny group@:r-x-----------:------:allow everyone@:-w-p---A-W-Co-:------:deny everyone@:r-x---a-R-c--s:------:allow The following example illustrates the ls -v behavior when listing ACL information on a UFS file. $ ls -v file.3 -rw-r--r-- 1 root root 2703 Mar 14 10:59 file.3 0:user::rw- 1:group::r-- #effective:r-- 2:mask:r-- 3:other:r-- I see considerable differences between the FreeBSD base ls and Solaris ls which does handle ACL data in both UFS and ZFS. Does this need to be dragged onto the table along with every other file handling tool and system call? I see a tarpit ( no pun intended ) this opens up. > For those not familiar with them (I am not very familiar myself;-), > a Solaris style extended attribute is in a directory that hangs off > the file object and the entries in the directory (the attributes) can > be manipulated with open/read/write/lseek just like a regular file. > (They can be as large as a regular file, but there is no atomicity > guarantees.) I just, today, shutdown my last Solaris server which was a Fujitsu SPARC64 machine and it was draining power and making heat for a number of years in my life. Certainly it was using ZFS but not the ZFS that we can use or "zfs send" anywhere. The botched up stuff that is totally not compatible with OpenZFS of any flavour. This means that I had to do a blunt force medieval tarball backup. Nothing else would ever be usable for recovery. Never in the many many years of using Solaris with ZFS have I felt the need to drag in xattr's on people. Not once in two decades. Pretty sure I did some very early testing within the OpenSolaris project and can not recall the desperate need thereafter. So who wants this? Why? Is there some atom-splitting world changing reason that the extended attributes are needed in FreeBSD? -- -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken ps: Jörg Schilling wrote a very xattr aware TAR in his schilytools https://github.com/clausecker/schilytools It is cross platform aware and already in ports as "star". https://cgit.freebsd.org/ports/tree/archivers/star/pkg-descr Being fast is a matter of opinion but I used it to backup my Fujitsu SPARC64 server today and the stats over 1Gbit NFSv3 are : pluto# tail -16 hubble_sparc64.star.log a 1564 -rw-r--r-- 1 root/root May 2 04:08 2024 var/dt/Xerrors a 5 -rw-r--r-- 1 root/root May 2 04:08 2024 var/dt/Xpid a 0 drwxr-xr-x 2 root/root May 2 04:08 2024 vol/ a 0 drwxr-xr-x 2 root/root May 5 22:31 2024 z/ star: Missing links to 'proc/183/fd/3'. star: Missing links to 'proc/108/object/a.out'. star: fifo had 20090580 puts 45730806 gets. star: fifo was 1092 times empty and 1548 times full. star: fifo held 268441600 bytes max, size was 268441600 bytes star: 45730806 blocks + 0 bytes (total of 468283453440 bytes = 457308060.00k). star: Total time 8539.200sec (53553 kBytes/sec) star: The following problems occurred during archive processing: star: Cannot: stat 2, open 0, read/write 42, chdir 0, iconv 349. star: Size changed 34. star: Missing links 2, Name too long 0, File too big 0, Not dumped 1. star: Processed all possible files, despite earlier errors. So yeah, it works and you can trust it. From nobody Sat Mar 29 00:29:57 2025 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 4ZPdZr1Tdvz5rgYl for ; Sat, 29 Mar 2025 00:30:12 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZPdZq3W43z3WSp for ; Sat, 29 Mar 2025 00:30:11 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x530.google.com with SMTP id 4fb4d7f45d1cf-5dca468c5e4so4736166a12.1 for ; Fri, 28 Mar 2025 17:30:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1743208209; x=1743813009; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=nJFeFB1vJtLUarCciK65744NYPg9LbBLxDIoxqhgPE0=; b=E/sMCUE8T5dc7Cy3J0lADS/uXRra/5RcCEt4zG4osp4L5IW74GNQbQ1kQNgrUtulHk eBweCg+E8Wxv36mpDQr5q6ylVNKqH1d5GBZlaKoNMw0WY8Xt5ZSnRMKQqQtxiOHHAxh0 L9mv0Hs8e4WeJ+PWhT65dH0XORSDkySQ5pubybwyg0om2uisse6BRN6dDOfx2xw1KXsA TPEVY3dVdfNFbtwLvbx39kfxi0pGFe75A439t29J6xNAwO/v3B72fc4UViMj9sHm3pX0 RQJE/U5s6yFjcL5z2hAK7F9gmcFCEK448Bl/Cx7RjvX8TwfuuOwGDirIS0yLZP8GDwnh xaSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743208209; x=1743813009; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=nJFeFB1vJtLUarCciK65744NYPg9LbBLxDIoxqhgPE0=; b=GXZVodSx9xPRN2nDvdDcuzFO/4fsY8GAFkyGghrmZRcTA7OUfRbc3ZCul+wkYxnNV1 uAvzyd1cyNHKHXbylKjZTuH++kirgGXACNlQKy2OqNpGmMWTpUQ7eAlRoGMhZuSOuNt7 suSwuYpbCSzj8qlNMo2OqiiNHF7v4BSaDuNxVS/dexe9bBS8wNgdhf9oqT64HzZeUAGx kxBR4PYh2Ppjl/H2g+pL0fzoD/zEO4nVtXJ1rfg1tEq6zJ+MUUYvDSmqX4Y0PSY4Uh7h rmrpgR5XyRdYiy2YfXPmiqiX3YA8wKwrbCeOPdwP0cGt77mUEnJvByFi96z3NzxOhbL0 GMDA== X-Gm-Message-State: AOJu0YwHwe9WUQodwErC/2vddqNLfaPpm26zqmxIKZRT1DC1rXAXSNEU zh7w+Pj1BzmRZvuAt5Zh8Y1ZsvwV5MsyCH2I0HGoXByFXFfpLGnQnRmPulH65gRxzvU1wdRqMm7 1u9daKmbSPGyFHaysct5xGgm/VO1UiOs= X-Gm-Gg: ASbGnct0Z4rtteKkHruCp4uCg8962LFuUvUn9/7vM7XKYLZFmYv8knTCHgSHcwinFPz 8M8azZVbqPDTrQ2gtPaXR/DPGWnjncs2UTRz33KCky14m2YGriPD4vzqaTvt8PEvnx7Vi2CLs98 eyBTVM5DePBR4mnjSxXlbIWGOwLtS87PQuNqHYXOFCcehpTiNm1mV9bQgH4g== X-Google-Smtp-Source: AGHT+IG5VsqbpzWrxiKcuRR1BJYxHag0mxbb6N5RxfLoDLWnX/h0pkWZVhly2UG7d910KNDnZ9MrP2w/srfjk9HcrAE= X-Received: by 2002:a05:6402:440f:b0:5ec:958b:6f5a with SMTP id 4fb4d7f45d1cf-5edfdbfe4f4mr869962a12.28.1743208209019; Fri, 28 Mar 2025 17:30:09 -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: <410014e4-75a6-4923-8f84-3935cab41c31@blastwave.org> In-Reply-To: <410014e4-75a6-4923-8f84-3935cab41c31@blastwave.org> From: Rick Macklem Date: Fri, 28 Mar 2025 17:29:57 -0700 X-Gm-Features: AQ5f1JrHpVX3hCsMyFYC2_Lr2Oz8tweJCBmuig5YQQOxA8kP2VfS8Ob43GkhgTE Message-ID: Subject: Re: RFC: Solaris style extended attributes for FreeBSD To: Dennis Clarke Cc: freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Queue-Id: 4ZPdZq3W43z3WSp X-Spamd-Bar: ---- On Fri, Mar 28, 2025 at 1:31=E2=80=AFPM Dennis Clarke wrote: > > On 3/8/25 18:02, Rick Macklem wrote: > > First off, I cross posted because I don't think many read freebsd-arch@= . > > There seems to be a nice market for Solaris style extended attributes. > > Hold on a moment. > > I have been following this discussion now for a while and I am trying to > figure who wants this? Why? Is this a "make work" project wherein a pile > of code and testing will needed? Where the word "pile" may mean years. > > > Since ZFS is already wired for them, adding the basics is pretty > > straightforward. I am not suggesting that they should replace the > > current FreeBSD extended attributes. > > > > Well if you decide to go into NFS with xattr then you may as well dig > into UFS with xattr also. Perhaps that would be insane however once you > deal with ACL handling in tools like tar and ls then you will need to > ponder UFS also. That means output similar to Solaris /usr/xpg4/bin/ls > like so : > > The following example shows how to display compact ACL > information on a ZFS directory. > > % ls -dV test.dir > drwxr-xr-x 2 marks staff 2 Mar 14 10:17 test.dir > owner@:--------------:------:deny > owner@:rwxp---A-W-Co-:------:allow > group@:-w-p----------:------:deny > group@:r-x-----------:------:allow > everyone@:-w-p---A-W-Co-:------:deny > everyone@:r-x---a-R-c--s:------:allow > > The following example illustrates the ls -v behavior when > listing ACL information on a UFS file. > > $ ls -v file.3 > -rw-r--r-- 1 root root 2703 Mar 14 10:59 file.3 > 0:user::rw- > 1:group::r-- #effective:r-- > 2:mask:r-- > 3:other:r-- > > I see considerable differences between the FreeBSD base ls and Solaris > ls which does handle ACL data in both UFS and ZFS. Does this need to > be dragged onto the table along with every other file handling tool > and system call? I see a tarpit ( no pun intended ) this opens up. > > > > For those not familiar with them (I am not very familiar myself;-), > > a Solaris style extended attribute is in a directory that hangs off > > the file object and the entries in the directory (the attributes) can > > be manipulated with open/read/write/lseek just like a regular file. > > (They can be as large as a regular file, but there is no atomicity > > guarantees.) > > I just, today, shutdown my last Solaris server which was a Fujitsu > SPARC64 machine and it was draining power and making heat for a number > of years in my life. Certainly it was using ZFS but not the ZFS that we > can use or "zfs send" anywhere. The botched up stuff that is totally not > compatible with OpenZFS of any flavour. This means that I had to do a > blunt force medieval tarball backup. Nothing else would ever be usable > for recovery. > > Never in the many many years of using Solaris with ZFS have I felt the > need to drag in xattr's on people. Not once in two decades. Pretty sure > I did some very early testing within the OpenSolaris project and can not > recall the desperate need thereafter. > > So who wants this? Why? Is there some atom-splitting world changing > reason that the extended attributes are needed in FreeBSD? Well, there is this email thread... https://lists.freebsd.org/archives/freebsd-hackers/2025-January/004194.html It does seem to be a niche interest. The individuals on that thread are her= e, so they can respond further. I, personally, cannot predict what users will want/need. ACLs are also of interest to a relatively small user population, from what I've seen. (I've been playing with it in part because it is low hanging fruit for ZFS, given that the named attribute API is under the other FreeBSD one. It is a part of NFSv4 that most have not implemented, given the predominanc= e of Linux systems.) rick > > > -- > -- > Dennis Clarke > RISC-V/SPARC/PPC/ARM/CISC > UNIX and Linux spoken > > ps: J=C3=B6rg Schilling wrote a very xattr aware TAR in his schilytools > > https://github.com/clausecker/schilytools > > It is cross platform aware and already in ports as "star". > > https://cgit.freebsd.org/ports/tree/archivers/star/pkg-descr > > Being fast is a matter of opinion but I used it to backup my > Fujitsu SPARC64 server today and the stats over 1Gbit NFSv3 are : > > pluto# tail -16 hubble_sparc64.star.log > a 1564 -rw-r--r-- 1 root/root May 2 04:08 2024 var/dt/Xerrors > a 5 -rw-r--r-- 1 root/root May 2 04:08 2024 var/dt/Xpid > a 0 drwxr-xr-x 2 root/root May 2 04:08 2024 vol/ > a 0 drwxr-xr-x 2 root/root May 5 22:31 2024 z/ > star: Missing links to 'proc/183/fd/3'. > star: Missing links to 'proc/108/object/a.out'. > star: fifo had 20090580 puts 45730806 gets. > star: fifo was 1092 times empty and 1548 times full. > star: fifo held 268441600 bytes max, size was 268441600 bytes > star: 45730806 blocks + 0 bytes (total of 468283453440 bytes =3D > 457308060.00k). > star: Total time 8539.200sec (53553 kBytes/sec) > star: The following problems occurred during archive processing: > star: Cannot: stat 2, open 0, read/write 42, chdir 0, iconv 349. > star: Size changed 34. > star: Missing links 2, Name too long 0, File too big 0, Not dumped 1. > star: Processed all possible files, despite earlier errors. > > So yeah, it works and you can trust it. > > > > > > From nobody Sat Mar 29 14:35:03 2025 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 4ZQ0Kx2zj3z5rXHb for ; Sat, 29 Mar 2025 14:35:17 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZQ0Kw4fNjz3pDf for ; Sat, 29 Mar 2025 14:35:16 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x535.google.com with SMTP id 4fb4d7f45d1cf-5ed1ac116e3so5253855a12.3 for ; Sat, 29 Mar 2025 07:35:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1743258915; x=1743863715; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=ltnY8r04hlOkRFNECRReX3MsBx5nMMbB0bS1bVZNHcw=; b=G3SnXzP6LedSwgrUYcoGNdQH9/8eZfEwzx2OlDW7obWcyKo1jEBvwlkS4/Dr14EAri RjoE7j2fFMQuxOYar47IhnaUvuHeFDzGk8J/eNmUcihUzJvvqvij97PZ7heEyU7g+53n Md3AISxSBj8SRhu+MLu3A27+moqu0m0YcXegzsDpXqwj9yazygTHEhzcwmlpSW3QjNxW qQcda5VEABIE7N4bSn5KqWvCY4IPhCXwrtdxfwlZYRmM2gtRwLSkcztPeQJygGMXAcdg pC3J5sP7Tm/UnhOGxjKQV+Y4djAsca47tpIeo5y/h7hf6DJ72ZpyZ4PtWgkykNXYZx4c ENeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743258915; x=1743863715; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ltnY8r04hlOkRFNECRReX3MsBx5nMMbB0bS1bVZNHcw=; b=LE/FXFJjf3S24kq+VWMNk0XLq94EZFPte7FwW4nbN7jhec1zrLhzGfs11pKiqBZNLu L+ncRGzoaWh6Lt2ix/IUaIGFZrinVZ7/FeKnC8+e2FgWMRlT9MCSZnIa97wQ1C6hiMJF 5owABdf8T67W1xJV5w/dp0jiiJuZRBjK0S8FutE7kOZQmw6Tf5wRPJmKkrMhhq6GGOpM C2vydeuS5ZosFmssX96qILkfwQkMhTm3HBWawNs/DU/2VQsNJJPiMkNQnKqRYMwId6Fm HhfH242knHMqjQxtoAMHuksdJRXoMb8H4lURlCZz05m3UoTaOhpvGWuYzKGHpXlD13Zh c3Sw== X-Gm-Message-State: AOJu0YzEefHIpHEXDlISBIndVQOR1kxh/wgij+6tc01k0anr0Y5Q9dnJ Tqx2tVKPkiwrr6K0rwdTUVMe2pGpQvSehTbii4PgAQlYcsE+tgE+XMc8g1kc1i2QllAEB9ehgpd bZa1xlRtEHDuR9bR4kgIAHAkYOg47 X-Gm-Gg: ASbGncsESWDyRR6xknUUKwWg0YYeTnw+lRTE0TcLyk8kuOLQj95qMFMpIeqYLhH+YjS +BZ576lO80TwuPU9de/jYvlZtcZi9a30Wcc0v1UcVDqydYuL5xwngX40M+RB3D3FFtD5/kIx4h/ 2TphGtciiAQHKxsidDC8z14nsrqchlSzFiy5OMFzikQfvWL9ks6BvdzN742A== X-Google-Smtp-Source: AGHT+IHTaubO1qxjw7QUS11ypSm8AEFkol7fJ/r3n4xEiP9iB6oSyrJc8NUhkHzQHkQfdZ064uX7+5fMvHRY1s1RzBI= X-Received: by 2002:a05:6402:1e8e:b0:5e5:c5f5:f78 with SMTP id 4fb4d7f45d1cf-5edfda04becmr2772655a12.26.1743258914347; Sat, 29 Mar 2025 07:35:14 -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: <410014e4-75a6-4923-8f84-3935cab41c31@blastwave.org> In-Reply-To: <410014e4-75a6-4923-8f84-3935cab41c31@blastwave.org> From: Rick Macklem Date: Sat, 29 Mar 2025 07:35:03 -0700 X-Gm-Features: AQ5f1JoZg-5O81lw249PuTsyJMCH7iP1SS8yr8GOt0xU4c0yato-RQtDQkmD-I4 Message-ID: Subject: Re: RFC: Solaris style extended attributes for FreeBSD To: Dennis Clarke Cc: freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Queue-Id: 4ZQ0Kw4fNjz3pDf X-Spamd-Bar: ---- On Fri, Mar 28, 2025 at 1:31=E2=80=AFPM Dennis Clarke wrote: > > On 3/8/25 18:02, Rick Macklem wrote: > > First off, I cross posted because I don't think many read freebsd-arch@= . > > There seems to be a nice market for Solaris style extended attributes. > > Hold on a moment. > > I have been following this discussion now for a while and I am trying to > figure who wants this? Why? Is this a "make work" project wherein a pile > of code and testing will needed? Where the word "pile" may mean years. > > > Since ZFS is already wired for them, adding the basics is pretty > > straightforward. I am not suggesting that they should replace the > > current FreeBSD extended attributes. > > > > Well if you decide to go into NFS with xattr then you may as well dig > into UFS with xattr also. Perhaps that would be insane however once you > deal with ACL handling in tools like tar and ls then you will need to > ponder UFS also. That means output similar to Solaris /usr/xpg4/bin/ls > like so : > > The following example shows how to display compact ACL > information on a ZFS directory. > > % ls -dV test.dir > drwxr-xr-x 2 marks staff 2 Mar 14 10:17 test.dir > owner@:--------------:------:deny > owner@:rwxp---A-W-Co-:------:allow > group@:-w-p----------:------:deny > group@:r-x-----------:------:allow > everyone@:-w-p---A-W-Co-:------:deny > everyone@:r-x---a-R-c--s:------:allow > > The following example illustrates the ls -v behavior when > listing ACL information on a UFS file. > > $ ls -v file.3 > -rw-r--r-- 1 root root 2703 Mar 14 10:59 file.3 > 0:user::rw- > 1:group::r-- #effective:r-- > 2:mask:r-- > 3:other:r-- > > I see considerable differences between the FreeBSD base ls and Solaris > ls which does handle ACL data in both UFS and ZFS. Does this need to > be dragged onto the table along with every other file handling tool > and system call? I see a tarpit ( no pun intended ) this opens up. Well, the NFSv4 ACLs exist now in FreeBSD for ZFS and no one has been pushi= ng for "ls" to know how to display them. (See getfacl(1)) ZFS also already supports extended attributes and, as above, "ls" does not know how to display them. (See lsextattr(1), getextattr(1)...) I do not see why commands like "ls" need to know about these things. tar/pax is a different story, since archival of them seems necessary. All the patches I have created does is add a different, Solaris like syscall/KABI for manipulating extended attributes. The patches just use code that is already in ZFS to handle the extended attributes as files in a directory. ZFS currently appears to store extended attributes two ways: "zfs set xattr=3Dsa " - For this one, small extended attributes are stored in some sort of storage block. If the extended attribute is too large for the storage block, it spills over into a file in a directory. --> The alternate syscall/KAPI does not work and is disabled for this property setting. "zfs set xattr=3Don " - Also called "dir", all extended attributes are stored as regular files, with a directory holding their names. --> The alternate syscall/KAPI the patches adds provides a more direct way to access this directory and the files that store the extended attributes. The main advantage of this syscall/KAPI is that large extended attributes are supported. Since this is already how ZFS stores extended attributes, I assume send/recv knows how to deal with them. tar/pax will need to know the alternate syscall/KAPI to handle large extended attributes if this syscall/KABI is used. (The thread I mentioned over on freebsd-hackers@ mentions a patched version of pax/tar, but I have not looked at it.) Do many people need/want to handle large extended attributes? I'd guess not, but I really have no idea what FreeBSD users use? (I only hear about problems w.r.t. NFS, so I have no idea how many use it without problems.) For NFSv4, this alternate model is supported as "named attributes". There i= s as extension to NFSv4.2 for the Linux/FreeBSD model for small extended attribu= tes, but this extension doesn't work for clients on Windows, Mac OSX or Solaris. As such, there is another niche market for some NFSv4 clients. The patches are rough, but basically done. I am now in testing mode. It was= not exactly a "make work" project. More a "I was curious to see how easily the Solaris style syscall/kapi could be implemented" project. I do not see any reason why UFS would need/want this alternate syscall/kapi= , since anyone wanting/needing large extended attributes could use ZFS, which is what most managed storage will use anyhow. In summary, other than the patches I've already done, a patched version of tar/pax is about all I think is needed. rick > > > > For those not familiar with them (I am not very familiar myself;-), > > a Solaris style extended attribute is in a directory that hangs off > > the file object and the entries in the directory (the attributes) can > > be manipulated with open/read/write/lseek just like a regular file. > > (They can be as large as a regular file, but there is no atomicity > > guarantees.) > > I just, today, shutdown my last Solaris server which was a Fujitsu > SPARC64 machine and it was draining power and making heat for a number > of years in my life. Certainly it was using ZFS but not the ZFS that we > can use or "zfs send" anywhere. The botched up stuff that is totally not > compatible with OpenZFS of any flavour. This means that I had to do a > blunt force medieval tarball backup. Nothing else would ever be usable > for recovery. > > Never in the many many years of using Solaris with ZFS have I felt the > need to drag in xattr's on people. Not once in two decades. Pretty sure > I did some very early testing within the OpenSolaris project and can not > recall the desperate need thereafter. > > So who wants this? Why? Is there some atom-splitting world changing > reason that the extended attributes are needed in FreeBSD? > > > -- > -- > Dennis Clarke > RISC-V/SPARC/PPC/ARM/CISC > UNIX and Linux spoken > > ps: J=C3=B6rg Schilling wrote a very xattr aware TAR in his schilytools > > https://github.com/clausecker/schilytools > > It is cross platform aware and already in ports as "star". > > https://cgit.freebsd.org/ports/tree/archivers/star/pkg-descr > > Being fast is a matter of opinion but I used it to backup my > Fujitsu SPARC64 server today and the stats over 1Gbit NFSv3 are : > > pluto# tail -16 hubble_sparc64.star.log > a 1564 -rw-r--r-- 1 root/root May 2 04:08 2024 var/dt/Xerrors > a 5 -rw-r--r-- 1 root/root May 2 04:08 2024 var/dt/Xpid > a 0 drwxr-xr-x 2 root/root May 2 04:08 2024 vol/ > a 0 drwxr-xr-x 2 root/root May 5 22:31 2024 z/ > star: Missing links to 'proc/183/fd/3'. > star: Missing links to 'proc/108/object/a.out'. > star: fifo had 20090580 puts 45730806 gets. > star: fifo was 1092 times empty and 1548 times full. > star: fifo held 268441600 bytes max, size was 268441600 bytes > star: 45730806 blocks + 0 bytes (total of 468283453440 bytes =3D > 457308060.00k). > star: Total time 8539.200sec (53553 kBytes/sec) > star: The following problems occurred during archive processing: > star: Cannot: stat 2, open 0, read/write 42, chdir 0, iconv 349. > star: Size changed 34. > star: Missing links 2, Name too long 0, File too big 0, Not dumped 1. > star: Processed all possible files, despite earlier errors. > > So yeah, it works and you can trust it. > > > > > > From nobody Sat Mar 29 16:15:10 2025 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 4ZQ2YH4Gvdz5rgSh for ; Sat, 29 Mar 2025 16:15:15 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-il1-x133.google.com (mail-il1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZQ2YG4RjLz3s2D for ; Sat, 29 Mar 2025 16:15:14 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=hardenedbsd.org header.s=google header.b=Ba+OUyHk; dmarc=none; spf=pass (mx1.freebsd.org: domain of shawn.webb@hardenedbsd.org designates 2607:f8b0:4864:20::133 as permitted sender) smtp.mailfrom=shawn.webb@hardenedbsd.org Received: by mail-il1-x133.google.com with SMTP id e9e14a558f8ab-3d589227978so9961545ab.1 for ; Sat, 29 Mar 2025 09:15:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd.org; s=google; t=1743264913; x=1743869713; darn=freebsd.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=mRKWg1HF2FbwyfoNIOV9V4TWZ5CKSL2zgYHJkPuXsUo=; b=Ba+OUyHkohYIflmimzaCj4Gk8BTQlHOUxeVf6JtH+i/qWbNKaa1VqM0gQ3UeQMWh2k lvp9fgSFOrOhiBN443MrQXQK/5/piJpWX0MpXoDQC4U2byEX7Rg6MAzYy/LRZBDULO05 9ktn4PxGo2VPZqp6Gv8xwxSZrAeJX0+u3YbgFtVngfOGztuMK1Wg1NmNv3PMQG2lLRzC VipoxLvecwjc8CM7TgLfNGZvnsCIlZgOgM1Wnz/ga5WNYGYZ3e/JpKu/TjId8NZyqoEJ f8S8/N2J5TNSSeflN6kemakqFCj3JNO8D80g7LMGh66xh8VJkwrSuGmH2a1wCUsqJrb2 4P8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743264913; x=1743869713; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=mRKWg1HF2FbwyfoNIOV9V4TWZ5CKSL2zgYHJkPuXsUo=; b=HEJZgdIqCaYZ3V4HpbpGF0ucVRTf23H0tC4m667BkghpLumqqvuZV8IUvyYZpbklSd PgV7g741PYl2ic2k3RFZTJ6L3BvdcyelUG4DRjMZ/S0scyFO30IbbZLFJ0uBXZpBJ2yu i4IzAlSTG12YpYJT7parywtlp41ewcD/aEYl6yCQdX3cYz9rFy6E3mumcUYvnTiRDq/H 2rP6XNLdrcp5PBXXB9HG1aMxTzSuHENfZ4Fxmt8D4K3tRLU2Q1Jj2F7qfxnFNDNM0Glh bVU9CDxyBGKwPioaQNCPfiYd+GZMDlnxb6Nn+QlQJF7thyL+JXUC3WuKkNBuGYdiLgk6 2mKA== X-Forwarded-Encrypted: i=1; AJvYcCUq1WNNL3HDuq9cNKwwpaOJv3TWbaE7NwWr7l82yC2xOSVMYtVhU2ZaDmevGvJkxk5WYxip725HalidaPz+3bM=@freebsd.org X-Gm-Message-State: AOJu0Yzltd+yaOUv+ad2jgKyvaIAUl/BQ04BGo8jKDqqdBYoDlrBluzI 3vvoh1mBlluxIYytxt+8brPHJqrxaqF+vXlLG2qOPMIuYe7eaYUMbMbDrQLa/Az4keoj+UvJgVo U8tw= X-Gm-Gg: ASbGncuRQf3x2FGvXTChu7oc80EWi7CrOmqBevRmICpTgQlMkZd3VNBtc6Qt0bvbbbK 6VukjfNce7GrnhCGK3dsqvvSYIHdX5ucTaJ73F+bat5ovWyES8IH90J16Z1HUWbHW/M59xeq/hc BKgsJBQsNqGWgtuyMzeff1UCttoJcxgbJCLaXa2EA4G0Gq4YNglVIUoEHI/PDc7CFlWKmO0Xo0w AH+dreyHa4nzUNYnWR1DO3BGsBXfMI22Q97g42BOwi9KXcb4pKmYkZb5ScN8mHNWxRbyWzJah0s nSpH2VTFtudZDNl3ENrPf6O4gR8= X-Google-Smtp-Source: AGHT+IHXoqqn7UFIH7hQfWJhPXGqEvQNhSi42BxDaqD8UmeLDNQnzcBlozdGpJuknUQwQTXHehC3HA== X-Received: by 2002:a05:6e02:156a:b0:3d4:2ea4:6b87 with SMTP id e9e14a558f8ab-3d5e0a10f4amr27493555ab.11.1743264913171; Sat, 29 Mar 2025 09:15:13 -0700 (PDT) Received: from mutt-hbsd ([2001:470:4001:1::95]) by smtp.gmail.com with ESMTPSA id e9e14a558f8ab-3d5d5ae9dbbsm10383835ab.52.2025.03.29.09.15.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 29 Mar 2025 09:15:12 -0700 (PDT) Date: Sat, 29 Mar 2025 16:15:10 +0000 From: Shawn Webb To: Rick Macklem Cc: Dennis Clarke , freebsd-current@freebsd.org Subject: Re: RFC: Solaris style extended attributes for FreeBSD Message-ID: X-Operating-System: FreeBSD mutt-hbsd 14.2-STABLE-HBSD FreeBSD 14.2-STABLE-HBSD HARDENEDBSD-14-STABLE amd64 X-PGP-Key: https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/blob/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc References: <410014e4-75a6-4923-8f84-3935cab41c31@blastwave.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: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="wqit7qhvmao6tdby" Content-Disposition: inline In-Reply-To: X-Spamd-Result: default: False [-4.72 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_LONG(-1.00)[-0.996]; NEURAL_HAM_MEDIUM(-0.90)[-0.904]; NEURAL_HAM_SHORT(-0.72)[-0.721]; MID_RHS_NOT_FQDN(0.50)[]; R_DKIM_ALLOW(-0.20)[hardenedbsd.org:s=google]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; DMARC_NA(0.00)[hardenedbsd.org]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[hardenedbsd.org:+]; RCPT_COUNT_THREE(0.00)[3]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_TO(0.00)[gmail.com]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; MISSING_XM_UA(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TAGGED_RCPT(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::133:from] X-Rspamd-Queue-Id: 4ZQ2YG4RjLz3s2D X-Spamd-Bar: ---- --wqit7qhvmao6tdby Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: RFC: Solaris style extended attributes for FreeBSD MIME-Version: 1.0 On Sat, Mar 29, 2025 at 07:35:03AM -0700, Rick Macklem wrote: > On Fri, Mar 28, 2025 at 1:31=E2=80=AFPM Dennis Clarke wrote: > > > > On 3/8/25 18:02, Rick Macklem wrote: > > > First off, I cross posted because I don't think many read freebsd-arc= h@. > > > There seems to be a nice market for Solaris style extended attributes. > > > > Hold on a moment. > > > > I have been following this discussion now for a while and I am trying to > > figure who wants this? Why? Is this a "make work" project wherein a pile > > of code and testing will needed? Where the word "pile" may mean years. > > > > > Since ZFS is already wired for them, adding the basics is pretty > > > straightforward. I am not suggesting that they should replace the > > > current FreeBSD extended attributes. > > > > > > > Well if you decide to go into NFS with xattr then you may as well dig > > into UFS with xattr also. Perhaps that would be insane however once you > > deal with ACL handling in tools like tar and ls then you will need to > > ponder UFS also. That means output similar to Solaris /usr/xpg4/bin/ls > > like so : > > > > The following example shows how to display compact ACL > > information on a ZFS directory. > > > > % ls -dV test.dir > > drwxr-xr-x 2 marks staff 2 Mar 14 10:17 test.dir > > owner@:--------------:------:deny > > owner@:rwxp---A-W-Co-:------:allow > > group@:-w-p----------:------:deny > > group@:r-x-----------:------:allow > > everyone@:-w-p---A-W-Co-:------:deny > > everyone@:r-x---a-R-c--s:------:allow > > > > The following example illustrates the ls -v behavior when > > listing ACL information on a UFS file. > > > > $ ls -v file.3 > > -rw-r--r-- 1 root root 2703 Mar 14 10:59 file.3 > > 0:user::rw- > > 1:group::r-- #effective:r-- > > 2:mask:r-- > > 3:other:r-- > > > > I see considerable differences between the FreeBSD base ls and Solaris > > ls which does handle ACL data in both UFS and ZFS. Does this need to > > be dragged onto the table along with every other file handling tool > > and system call? I see a tarpit ( no pun intended ) this opens up. > Well, the NFSv4 ACLs exist now in FreeBSD for ZFS and no one has been pus= hing > for "ls" to know how to display them. (See getfacl(1)) >=20 > ZFS also already supports extended attributes and, as above, "ls" does not > know how to display them. (See lsextattr(1), getextattr(1)...) >=20 > I do not see why commands like "ls" need to know about these things. > tar/pax is a different story, since archival of them seems necessary. >=20 > All the patches I have created does is add a different, Solaris like > syscall/KABI > for manipulating extended attributes. The patches just use code that > is already in ZFS to > handle the extended attributes as files in a directory. > ZFS currently appears to store extended attributes two ways: > "zfs set xattr=3Dsa " - For this one, small extended > attributes are stored > in some sort of storage block. If the extended attribute is too > large for the storage > block, it spills over into a file in a directory. > --> The alternate syscall/KAPI does not work and is disabled for > this property setting. >=20 > "zfs set xattr=3Don " - Also called "dir", all extended > attributes are stored > as regular files, with a directory holding their names. > --> The alternate syscall/KAPI the patches adds provides a more > direct way to access > this directory and the files that store the extended attributes. > The main advantage of this syscall/KAPI is that large extended > attributes are supported. >=20 > Since this is already how ZFS stores extended attributes, I assume > send/recv knows > how to deal with them. tar/pax will need to know the alternate > syscall/KAPI to handle > large extended attributes if this syscall/KABI is used. (The thread I > mentioned over > on freebsd-hackers@ mentions a patched version of pax/tar, but I have > not looked at it.) >=20 > Do many people need/want to handle large extended attributes? > I'd guess not, but I really have no idea what FreeBSD users use? > (I only hear about problems w.r.t. NFS, so I have no idea how many use > it without > problems.) > For NFSv4, this alternate model is supported as "named attributes". There= is as > extension to NFSv4.2 for the Linux/FreeBSD model for small extended attri= butes, > but this extension doesn't work for clients on Windows, Mac OSX or Solari= s. > As such, there is another niche market for some NFSv4 clients. >=20 > The patches are rough, but basically done. I am now in testing mode. It w= as not > exactly a "make work" project. More a "I was curious to see how easily > the Solaris > style syscall/kapi could be implemented" project. >=20 > I do not see any reason why UFS would need/want this alternate syscall/ka= pi, > since anyone wanting/needing large extended attributes could use ZFS, whi= ch > is what most managed storage will use anyhow. >=20 > In summary, other than the patches I've already done, a patched version of > tar/pax is about all I think is needed. >=20 I had added filesystem extended attribute support to libarchive, which is what FreeBSD's tar(1) is based off of. I upstreamed that, so that's taken care of. FreeBSD's tar(1) has supported extended attributes since 2020 (see libarchive PR 1409: https://github.com/libarchive/libarchive/pull/1409) > > > For those not familiar with them (I am not very familiar myself;-), > > > a Solaris style extended attribute is in a directory that hangs off > > > the file object and the entries in the directory (the attributes) can > > > be manipulated with open/read/write/lseek just like a regular file. > > > (They can be as large as a regular file, but there is no atomicity > > > guarantees.) > > > > I just, today, shutdown my last Solaris server which was a Fujitsu > > SPARC64 machine and it was draining power and making heat for a number > > of years in my life. Certainly it was using ZFS but not the ZFS that we > > can use or "zfs send" anywhere. The botched up stuff that is totally not > > compatible with OpenZFS of any flavour. This means that I had to do a > > blunt force medieval tarball backup. Nothing else would ever be usable > > for recovery. > > > > Never in the many many years of using Solaris with ZFS have I felt the > > need to drag in xattr's on people. Not once in two decades. Pretty sure > > I did some very early testing within the OpenSolaris project and can not > > recall the desperate need thereafter. > > > > So who wants this? Why? Is there some atom-splitting world changing > > reason that the extended attributes are needed in FreeBSD? Just one data point here: HardenedBSD uses filesystem extended attributes to toggle certain exploit mitigations on a per-application basis. That's why we added support to libarchive: so we can ship certain packages with exploit mitigations pre-toggled. Thanks, --=20 Shawn Webb Cofounder / Security Engineer HardenedBSD Tor-ified Signal: +1 303-901-1600 / shawn_webb_opsec.50 https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A= 4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc --wqit7qhvmao6tdby Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEA6TL67gupaZ9nzhT/y5nonf44foFAmfoHIcACgkQ/y5nonf4 4fofqQ//byGPGpoAlkeAiTXrTFhtSrJeOZG1r3hfaP7NuzZPJ9ead/Idx8MENIxV C3xJMkRragYBGj0P3+CVMuIDnNIRubCmFyXi3sNeZZqrIWRZt7F4q3FkNrFCN+MU SP0VVS1mZcWLuxWQ+d6ZAhrqhBzp6iwA6UtP3qG2FbD3Fau0y1Q11/7Vf3DYW021 1pXaPIaFTEff9VHaIpWeheWrz9kIGhn1TAucuAKLzv1L10KL+OLF9rCHEtUogMUz x5LUMzQK0h0IR73kRQDP8Sy22hHhcYIsCLw6gfMnUqEIPatBehHUL3uYkHpM7BCV JO4VhxhW+1X8nRyPwsLkP4WxKbNH8Ph+RTqu4jRVajRO9TdhzqsID+1NlRIgt9qq y4G9B7wdQJRhQNt4xgf10QwhgR6J+MpdITNENov0NBVkFrB2k4w/d3AdELrostcB 1taVpTlDPli+IV0zLjHj2cQ7kPMi9jYk7ld8/Ixa4ZghtE8K/ZBQAie3GpNn1pNY RvlPtsAEchejWRrogKUwH8A0gtraWP0mwxrZr6LnsILiHXtu9pU5Md99/KPU1WZV BRfqLZ4R1KMSoykmKF0QJp4EsX4doM++9gAtL/tP92u1gn24uaM9/FtkqLeuKccP ypviHuDMB7/6Ym2hX7gJoAb8Sg6Dyz+SC0LgrKfqLyyNGX6scF8= =52N/ -----END PGP SIGNATURE----- --wqit7qhvmao6tdby-- From nobody Sat Mar 29 19:39:02 2025 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 4ZQ74g72KFz5ry7j for ; Sat, 29 Mar 2025 19:39:15 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZQ74g4p9Vz49Z6 for ; Sat, 29 Mar 2025 19:39:15 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x52e.google.com with SMTP id 4fb4d7f45d1cf-5e6ff035e9aso1684997a12.0 for ; Sat, 29 Mar 2025 12:39:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1743277153; x=1743881953; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=uGdIWI7xzm8gNmw8WOwoNTdxbea+HsYhbyYsFLrSXDs=; b=SSQczQKBC7+fQXjphx/w91+Q/BWep/lEAQwqC0n6hreSdd6TuE73e5+w6UOqLiw4Nn qrk/DdwvOiRHY/917KQbdMLZLnFixLfmB9+Vyytb/s5jpJT4Ol3kJHo1+5D/EtrMKE1N BHe4FK4ufH13JuGaZhoKql7kl2qKnR5TZM6YiDoO3rpS+rvH7PKuZC8HHLHKMw5TGTUs 2dCvQ4/mb2XR6sxecdNTe/TuP/Nzop2Rv+K8eWJe348iRac/rZnNzTM6/YGxJjKR0R/w 9jlZvwh7UyCDCiQLlQBLJILoDEqk1nDmN/pW5RzmdiyFOwfy1Da/QADKTvhLSSEVn677 MTag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743277153; x=1743881953; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=uGdIWI7xzm8gNmw8WOwoNTdxbea+HsYhbyYsFLrSXDs=; b=iMUl7xXqYDz3w8aBn1RnoYIvgellitZCNk3XUpqSp+hwvXN5Sa8yHU9vOw2MuKQ7Mp 3TBvGye3AijdXxBypvTKU04fmDAB7+IKuHhQ7IZoCeRya4Hf9v8IN+JlKtMftH+cXdNK h2rPiKrCKw9JcCdN1Ld8fFiiTymNlatZpy+riN8bzwPVHKMQj+knzZT0+er6SJzF/xPB gYjHbOkF4Zpw8XIBpTyC+JL3zNTJx+LAwH1LJjxf0RH8LeG/EDgBv4J5v/lAkliwHLmz 8Z67HjHB/byWENqNCUzTE3QcdDWjLi4VCr8RoVLjCXMObeULxMfThQhh864WG8zsusRe mLmQ== X-Forwarded-Encrypted: i=1; AJvYcCVLXl6nNJ16WNGbwGkPNv59AWBxqNJTdQLbB6jIlQAF0Nm2oGg6vk2IeyPJZeHTrQmFfPjpu/yfApJ0Hg70XHk=@freebsd.org X-Gm-Message-State: AOJu0YwUNig20GY62mQQwK5kox4zOtd6en2TEd9YcfZBWi/IJ2sYY94Y fA/9Fv30b6w/GcsD+/NTELx5Zi72raf7hndGDdOznnFkx6lfZPoCYTeCvuxA8qlfmIaMvOEQLS/ ZUQ5PxeYpNv8bxcSJMjttdLX8FB6f X-Gm-Gg: ASbGnctoVpcjNTwAemBhCE/pa+C/FvELIxp64A1uq8xS74lQ/Qjz0YIrE1tYyLbVsW4 P5uJPsnU+G9vVjL3DGAy9IJ1o/b32g+q0+RCCBeMa+OpIlrckqfSzTgJ5jwGDnLpQrRNfRHZLyR 1mzJETtP4GLstMcDpsEyD4pMfzCccPyq94kEXboq6bcIP/84PL85qLZ/VEeqVZM93rruCg X-Google-Smtp-Source: AGHT+IGchxsqIYH27fSlMsYGFhesLRAHhTU59JlX3Yl+qEiQJwQzVHCFRq6B9MEXPsKme0owSZb0Jjx0IyxpOo3Ji3s= X-Received: by 2002:a05:6402:3604:b0:5ed:1841:18c5 with SMTP id 4fb4d7f45d1cf-5edfdd21ad3mr3241906a12.30.1743277152772; Sat, 29 Mar 2025 12:39: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: <410014e4-75a6-4923-8f84-3935cab41c31@blastwave.org> In-Reply-To: From: Rick Macklem Date: Sat, 29 Mar 2025 12:39:02 -0700 X-Gm-Features: AQ5f1JoIrkSSP2VwrutLq-5n-DecBxqAuk7WL4zSPQVh5pNH7x5MUQ4rBN-yUYk Message-ID: Subject: Re: RFC: Solaris style extended attributes for FreeBSD To: Shawn Webb Cc: Dennis Clarke , freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Queue-Id: 4ZQ74g4p9Vz49Z6 X-Spamd-Bar: ---- On Sat, Mar 29, 2025 at 9:15=E2=80=AFAM Shawn Webb wrote: > > On Sat, Mar 29, 2025 at 07:35:03AM -0700, Rick Macklem wrote: > > On Fri, Mar 28, 2025 at 1:31=E2=80=AFPM Dennis Clarke wrote: > > > > > > On 3/8/25 18:02, Rick Macklem wrote: > > > > First off, I cross posted because I don't think many read freebsd-a= rch@. > > > > There seems to be a nice market for Solaris style extended attribut= es. > > > > > > Hold on a moment. > > > > > > I have been following this discussion now for a while and I am trying= to > > > figure who wants this? Why? Is this a "make work" project wherein a p= ile > > > of code and testing will needed? Where the word "pile" may mean years= . > > > > > > > Since ZFS is already wired for them, adding the basics is pretty > > > > straightforward. I am not suggesting that they should replace the > > > > current FreeBSD extended attributes. > > > > > > > > > > Well if you decide to go into NFS with xattr then you may as well dig > > > into UFS with xattr also. Perhaps that would be insane however once y= ou > > > deal with ACL handling in tools like tar and ls then you will need to > > > ponder UFS also. That means output similar to Solaris /usr/xpg4/bin/l= s > > > like so : > > > > > > The following example shows how to display compact ACL > > > information on a ZFS directory. > > > > > > % ls -dV test.dir > > > drwxr-xr-x 2 marks staff 2 Mar 14 10:17 test.= dir > > > owner@:--------------:------:deny > > > owner@:rwxp---A-W-Co-:------:allow > > > group@:-w-p----------:------:deny > > > group@:r-x-----------:------:allow > > > everyone@:-w-p---A-W-Co-:------:deny > > > everyone@:r-x---a-R-c--s:------:allow > > > > > > The following example illustrates the ls -v behavior when > > > listing ACL information on a UFS file. > > > > > > $ ls -v file.3 > > > -rw-r--r-- 1 root root 2703 Mar 14 10:59 file.= 3 > > > 0:user::rw- > > > 1:group::r-- #effective:r-- > > > 2:mask:r-- > > > 3:other:r-- > > > > > > I see considerable differences between the FreeBSD base ls and Solari= s > > > ls which does handle ACL data in both UFS and ZFS. Does this need to > > > be dragged onto the table along with every other file handling tool > > > and system call? I see a tarpit ( no pun intended ) this opens up. > > Well, the NFSv4 ACLs exist now in FreeBSD for ZFS and no one has been p= ushing > > for "ls" to know how to display them. (See getfacl(1)) > > > > ZFS also already supports extended attributes and, as above, "ls" does = not > > know how to display them. (See lsextattr(1), getextattr(1)...) > > > > I do not see why commands like "ls" need to know about these things. > > tar/pax is a different story, since archival of them seems necessary. > > > > All the patches I have created does is add a different, Solaris like > > syscall/KABI > > for manipulating extended attributes. The patches just use code that > > is already in ZFS to > > handle the extended attributes as files in a directory. > > ZFS currently appears to store extended attributes two ways: > > "zfs set xattr=3Dsa " - For this one, small extended > > attributes are stored > > in some sort of storage block. If the extended attribute is too > > large for the storage > > block, it spills over into a file in a directory. > > --> The alternate syscall/KAPI does not work and is disabled for > > this property setting. > > > > "zfs set xattr=3Don " - Also called "dir", all extended > > attributes are stored > > as regular files, with a directory holding their names. > > --> The alternate syscall/KAPI the patches adds provides a more > > direct way to access > > this directory and the files that store the extended attributes= . > > The main advantage of this syscall/KAPI is that large extended > > attributes are supported. > > > > Since this is already how ZFS stores extended attributes, I assume > > send/recv knows > > how to deal with them. tar/pax will need to know the alternate > > syscall/KAPI to handle > > large extended attributes if this syscall/KABI is used. (The thread I > > mentioned over > > on freebsd-hackers@ mentions a patched version of pax/tar, but I have > > not looked at it.) > > > > Do many people need/want to handle large extended attributes? > > I'd guess not, but I really have no idea what FreeBSD users use? > > (I only hear about problems w.r.t. NFS, so I have no idea how many use > > it without > > problems.) > > For NFSv4, this alternate model is supported as "named attributes". The= re is as > > extension to NFSv4.2 for the Linux/FreeBSD model for small extended att= ributes, > > but this extension doesn't work for clients on Windows, Mac OSX or Sola= ris. > > As such, there is another niche market for some NFSv4 clients. > > > > The patches are rough, but basically done. I am now in testing mode. It= was not > > exactly a "make work" project. More a "I was curious to see how easily > > the Solaris > > style syscall/kapi could be implemented" project. > > > > I do not see any reason why UFS would need/want this alternate syscall/= kapi, > > since anyone wanting/needing large extended attributes could use ZFS, w= hich > > is what most managed storage will use anyhow. > > > > In summary, other than the patches I've already done, a patched version= of > > tar/pax is about all I think is needed. > > > > I had added filesystem extended attribute support to libarchive, which > is what FreeBSD's tar(1) is based off of. I upstreamed that, so that's > taken care of. FreeBSD's tar(1) has supported extended attributes > since 2020 (see libarchive PR 1409: > https://github.com/libarchive/libarchive/pull/1409) Ok, thanks for the info. If this stuff goes into FreeBSD, it probably needs to be tweaked to use the different syscall API so that it can handle large attributes and maybe the attribute's mode. (someday, maybe?) rick > > > > > For those not familiar with them (I am not very familiar myself;-), > > > > a Solaris style extended attribute is in a directory that hangs off > > > > the file object and the entries in the directory (the attributes) c= an > > > > be manipulated with open/read/write/lseek just like a regular file. > > > > (They can be as large as a regular file, but there is no atomicity > > > > guarantees.) > > > > > > I just, today, shutdown my last Solaris server which was a Fujitsu > > > SPARC64 machine and it was draining power and making heat for a numbe= r > > > of years in my life. Certainly it was using ZFS but not the ZFS that= we > > > can use or "zfs send" anywhere. The botched up stuff that is totally = not > > > compatible with OpenZFS of any flavour. This means that I had to do a > > > blunt force medieval tarball backup. Nothing else would ever be usabl= e > > > for recovery. > > > > > > Never in the many many years of using Solaris with ZFS have I felt th= e > > > need to drag in xattr's on people. Not once in two decades. Pretty su= re > > > I did some very early testing within the OpenSolaris project and can = not > > > recall the desperate need thereafter. > > > > > > So who wants this? Why? Is there some atom-splitting world changing > > > reason that the extended attributes are needed in FreeBSD? > > Just one data point here: HardenedBSD uses filesystem extended > attributes to toggle certain exploit mitigations on a per-application > basis. That's why we added support to libarchive: so we can ship > certain packages with exploit mitigations pre-toggled. Just curious. Does it use "system" or "user" attribute space? rick > > Thanks, > > -- > Shawn Webb > Cofounder / Security Engineer > HardenedBSD > > Tor-ified Signal: +1 303-901-1600 / shawn_webb_opsec.50 > https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/0= 3A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc From nobody Sat Mar 29 19:50:37 2025 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 4ZQ7Ks4Ty5z5rylr for ; Sat, 29 Mar 2025 19:50:41 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-il1-x136.google.com (mail-il1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZQ7Kr5v5Mz3L7b for ; Sat, 29 Mar 2025 19:50:40 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=hardenedbsd.org header.s=google header.b=ZkBIC8mx; dmarc=none; spf=pass (mx1.freebsd.org: domain of shawn.webb@hardenedbsd.org designates 2607:f8b0:4864:20::136 as permitted sender) smtp.mailfrom=shawn.webb@hardenedbsd.org Received: by mail-il1-x136.google.com with SMTP id e9e14a558f8ab-3ce868498d3so11566445ab.3 for ; Sat, 29 Mar 2025 12:50:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd.org; s=google; t=1743277839; x=1743882639; darn=freebsd.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=S3ueps1v4+ZjrFerWxHg48SwzMsZinI+vR45yQ92WQ8=; b=ZkBIC8mxp2kirTFxXTXvmItPEXBtLsyHLlCwyLwsBskk3rqTSU04kwCjuOkMMYFp27 CLXuem4cBTzaAJ2QEB4OlgmBztIAo/+CQVHtfZ+N9lR2YE69xicuuSJfDYwkoKmbYvgS nW9ijN6+TfoKssdcLbcuQMdJg5ixnnFeozeL4C7v0XvvGGLSN+O1W6vJ3ZxqDm0ixV35 qw+sTqSMu4MGlRFVmKhuj0zGFDnjmwIGyDf1jVD4M1d5HpwIoh1aQ5yHP11/6ORdzLEs RNUWWMZIiXn3Pm61b+YMhbuY0yRGNY37ljHmXg6KtLKVpCjYRI/y6TonEWRZWRqs3pSN eXSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743277839; x=1743882639; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=S3ueps1v4+ZjrFerWxHg48SwzMsZinI+vR45yQ92WQ8=; b=aJyqJ/Jc3RX3/bLiCKJIsrTnlqfPi6ivdMPjJry8xYrTrW+ThqHvzoRq2hPSX4eNXz 7lh/syVN6dRxudbpC9fcnGL8dP1/mHKSzJA3Md3CUhSYo9XdMkaFLP3NUaBps/puqrL6 58ZWt3yTjB2C/1OrW8EuNIY2lbGAtVr7UNAeTpy/hpCDL4ArHs/xYAOUwlofXWF+aKYm kV9sYUjTRUNdGzT5b3ShjifajBKQv/lOungE9jLEIEb6KKa/1/x5u4cYm1c8ZOi/76Ry YlV+jQZdzV+qb8G8EH+qvYLbxKbnX3d5RoCNx2ajXDtA9sNy03MuS67I4UCVUloQWfGx qV9Q== X-Forwarded-Encrypted: i=1; AJvYcCUR1sET2EUEGVmty0fEGfmgJjI/1O6OUkFRpF4p+fKYXq4zius7QmM5v7Se5ulLvDWYLuchsWcPYOcT7PrVZJc=@freebsd.org X-Gm-Message-State: AOJu0Yy5r2pr0JWkvWzXnV0kwbOVWRXXQYxFIDzhHqS7l4qsHe8eBb1q UuqE9+Ov/4dw4GQnkoTmoDQIUXxeuJ+74Nxz+7/M+FmuXMBKXajDSSPUOuyorlI= X-Gm-Gg: ASbGncsgL45Licpwfb5+w05zU1SUjMPrhlXuV0nWjdcl6Ir0djsQ996MwuoYSdyvbDt AbM1wKXrxfeTPwN0r6sRNkdEJm8dDdfrBsSJPtUaTyIxe02hD+3Mj0EKMggqHTC6m7BnAj5qYVK TKSGJ7qa/1obEcugR1ZOHbx5IS8BseLRArMNI0ecZ4eho4DmA5jSZ4u6tg1K7KNkMtx1vKtoa0U m777xo0nP3An+vTY8iogJRDJlpjRUdQiuWl/pXJSwDReZCHpgc50MUgQiDD1Ignom3RjN6k+T5d tyO240wWGZm2lC1409s0v5ZM5TE= X-Google-Smtp-Source: AGHT+IGi6lzm2Y05+T75/Rf/IfoX/JSEaNuRQngxyyth+PVna4KF7VuaT4MKRYyxoTG0f4RGTGhweg== X-Received: by 2002:a05:6e02:3a04:b0:3d1:966c:fc8c with SMTP id e9e14a558f8ab-3d5e09f7834mr31662295ab.17.1743277839527; Sat, 29 Mar 2025 12:50:39 -0700 (PDT) Received: from mutt-hbsd ([2001:470:4001:1::95]) by smtp.gmail.com with ESMTPSA id 8926c6da1cb9f-4f46473f1f6sm1041956173.33.2025.03.29.12.50.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 29 Mar 2025 12:50:38 -0700 (PDT) Date: Sat, 29 Mar 2025 19:50:37 +0000 From: Shawn Webb To: Rick Macklem Cc: Dennis Clarke , freebsd-current@freebsd.org Subject: Re: RFC: Solaris style extended attributes for FreeBSD Message-ID: <3dso3cojzxnylcfmpmgwzizp4omzpmnbfgz3zt5pvgeur4wss6@kblfkmtssebw> X-Operating-System: FreeBSD mutt-hbsd 14.2-STABLE-HBSD FreeBSD 14.2-STABLE-HBSD HARDENEDBSD-14-STABLE amd64 X-PGP-Key: https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/blob/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc References: <410014e4-75a6-4923-8f84-3935cab41c31@blastwave.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: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="glikkbzwkjj4siap" Content-Disposition: inline In-Reply-To: X-Spamd-Result: default: False [-4.80 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.998]; NEURAL_HAM_LONG(-1.00)[-0.997]; NEURAL_HAM_SHORT(-0.71)[-0.706]; MID_RHS_NOT_FQDN(0.50)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; R_DKIM_ALLOW(-0.20)[hardenedbsd.org:s=google]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[hardenedbsd.org:+]; RCPT_COUNT_THREE(0.00)[3]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_TO(0.00)[gmail.com]; ARC_NA(0.00)[]; DMARC_NA(0.00)[hardenedbsd.org]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; MISSING_XM_UA(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TAGGED_RCPT(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::136:from] X-Rspamd-Queue-Id: 4ZQ7Kr5v5Mz3L7b X-Spamd-Bar: ---- --glikkbzwkjj4siap Content-Type: text/plain; protected-headers=v1; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: RFC: Solaris style extended attributes for FreeBSD MIME-Version: 1.0 On Sat, Mar 29, 2025 at 12:39:02PM -0700, Rick Macklem wrote: > > I had added filesystem extended attribute support to libarchive, which > > is what FreeBSD's tar(1) is based off of. I upstreamed that, so that's > > taken care of. FreeBSD's tar(1) has supported extended attributes > > since 2020 (see libarchive PR 1409: > > https://github.com/libarchive/libarchive/pull/1409) > Ok, thanks for the info. If this stuff goes into FreeBSD, it probably nee= ds > to be tweaked to use the different syscall API so that it can handle large > attributes and maybe the attribute's mode. (someday, maybe?) I believe libarchive has been updated in FreeBSD since October 2020, so the vendored libarchive in FreeBSD should already support it. But, yeah, if FreeBSD makes changes to how extended attributes work, I or someone else would need to update libarchive to account for that. Since HardenedBSD follows FreeBSD closely (we sync every six hours), I would probably volunteer to update the libarchive code. > > Just one data point here: HardenedBSD uses filesystem extended > > attributes to toggle certain exploit mitigations on a per-application > > basis. That's why we added support to libarchive: so we can ship > > certain packages with exploit mitigations pre-toggled. > Just curious. Does it use "system" or "user" attribute space? We use the system namespace, though the userland tool (hbsdcontrol) was recently taught about the user namespace. The kernel side only supports system namespace. So the user namespace support in hbsdcontrol is somewhat meaningless. I do plan to eventually get to the kernel side, but my TODO list continues growing. :-) Thanks, --=20 Shawn Webb Cofounder / Security Engineer HardenedBSD Tor-ified Signal: +1 303-901-1600 / shawn_webb_opsec.50 https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A= 4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc --glikkbzwkjj4siap Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEA6TL67gupaZ9nzhT/y5nonf44foFAmfoTwUACgkQ/y5nonf4 4foj2BAApZMuqQy+32YutBrw/UPEz2gt2hlfb1u4JR7FoeZRs9cEGTBNrKoJjngc X6hBgw9aYUZbABLC2bn3HGnSZ8Al/SlDj/qUzSGzMoeBgqzKMH54LPssBQ+x1u/W g/iY4iu3j87SMTw4prS1Zz62q9vV/lAOo2xgM1MXo6R5yUVaxN+aT8oVOt/F+BKs APSz7SzcdV1ccGTKoeZLwNyoqdQQDJJpA+twFDOaPU1SPRrUMU5dS/eQHx3Gf2VD FXxUu7TMRHrMOj8rPdnRJv84o+aJWd0XCzgcr6qSuouoLogtlpUh8RqSTGAbNW6G QMFZAN7vpFCCGBkK3HmKTN/RgvEXqUJJHnslxOuw/2aYLZrgpXtTEHBRbRr6agcL fC3hL1flCAMzwEW1zq5ZARamK5hasMcEAOY3FjJWe6fNy96G4Tn3gYClUD0Qayi1 cY+/cUf2f0l4S2anIxrlNsMU+fAJIR2Hgvxaj8r8hp8ccJkkPnB72SWuA6nGxy2w /nWPaEPda9FArGcRqI38Cwe06OJfw3MjtBL+7bvDUf26e5VKZwu2wddWb3IbXlwC KEJ17CqFUAuOSGWdCRdHLEhQ7J0Vgj/HVXaR/opucWtChZDfWX8yS+b6Zq4V4cUm JvINGaR7NmpnmsgjjSpNimNdJdyu+WvxunHLT7nfItICVdWyzcs= =taP7 -----END PGP SIGNATURE----- --glikkbzwkjj4siap-- From nobody Sat Mar 29 20:04:08 2025 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 4ZQ7dc4Vz6z5s188 for ; Sat, 29 Mar 2025 20:04:20 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZQ7dc2KGJz3Vmy for ; Sat, 29 Mar 2025 20:04:20 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x530.google.com with SMTP id 4fb4d7f45d1cf-5e5c9662131so5009206a12.3 for ; Sat, 29 Mar 2025 13:04:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1743278659; x=1743883459; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=MV2btYa5bjHa4dDBDafGDhN48XxHPX7q+PLp0+WksBU=; b=N17l3BTO6Sxtzuqb35h6x1f9lAth/eMKMSXGCgCyT198n0lc5Mp0EjSRL0kAW3GK5Q Bp/gkadTeo/j0RSiBGMe++6eb9iuzrlr35PNmXRSmHCHssE8Q7G+xlkwOw4ucweogTae nQfmThCgjGdqDIqvW5k0tQdVD8HAWwrqZMr9LawpuEM9zjRvg23S13Nur/8WXm5CLy71 4YtdVV2LbXEXhHkLavYPnU2z95F4BYaciuEAJLembTswuRwJkszq0RnVKnZWSj0lOABS 2wH9E5tYUr/8Ja6WPSiffmGhvbr+QKJT4AOpUEcbwkFWeNNl07o3EDNbvIQvVECeo93B OWVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743278659; x=1743883459; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=MV2btYa5bjHa4dDBDafGDhN48XxHPX7q+PLp0+WksBU=; b=X6n0ee9rupaTeLEunDEC2Nus3vS7AQDGg95fOVjcca6SQEGcHEBLwf8DTntOR7WJG7 09b3yGsKbWhrIyBkHsfOg2DJAfrjc+TgLgBtueXx+JdRCeGpQByRdBHV+L08GmD7iXBf I6nibSf5oKThPB1QoI5FxuUZYr73sWrYLNru7MTCjfeE3Kpi/qTbQ2Y7A719v++czyYX gauT6v0+mGjR+/18t0X0nj31iZb9igoI1pOEIV4DSIWCc07BwujBxfErwvP5eVmhn+0C j8yqtt+lzRpUsoNUFHFRvLzDpD1DMFyLt3YJXRozXsnn70LBXdK2yy1ZTej04hcKwNSE AOWg== X-Forwarded-Encrypted: i=1; AJvYcCWVwu77eTKFLYEygX9NUXiKPsufpgt34GkcLsEncf1SDA4lxwgnvaO9FLmY2Id15id3T4VO+y34V8zIGTJe0VA=@freebsd.org X-Gm-Message-State: AOJu0Yz2Ec9bcWeP2YCmO/tIu2m0kKmDjdCwwkLxT3ICyBD1MQyN800o UCuNY8zTO85uud8FYuTcjLoddjUMz5ZwnHe7Ugs/v+cWmX+sFrOufQcizXDBF9xIcQdXmawxgGI 1970zO5mnRXu1yjNMfX0j4c4zJAJ5 X-Gm-Gg: ASbGnctK2wlKoQF42GQGlYehOTrQo1iznp5JWuZKmFfxguzI+I1fgIeNVHePLLgNhxi 4y3se4Hhs6OJ69PVZTgd0mN2/w6Qt42eORsjVpmiiRhGDnzsV+dlKrL7F0zFHMED/AKZiXjfpez dBdIfFrM8Dfe3vbTYH/hVeIB3M/QzQL9D2qdTFqpbd+jPVWoeOS1TdFd7+LA== X-Google-Smtp-Source: AGHT+IFBjd3fkOiPBEEUzqPObypORsHmLaQzvZ/kNPvTNqCejJndhy0PdEfBHk84B0zIdIWY3gDtLaP+HopIWL7LsXQ= X-Received: by 2002:a05:6402:348e:b0:5eb:cc1c:bb9e with SMTP id 4fb4d7f45d1cf-5edfcc2724dmr3698002a12.7.1743278658663; Sat, 29 Mar 2025 13:04:18 -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: <410014e4-75a6-4923-8f84-3935cab41c31@blastwave.org> <3dso3cojzxnylcfmpmgwzizp4omzpmnbfgz3zt5pvgeur4wss6@kblfkmtssebw> In-Reply-To: <3dso3cojzxnylcfmpmgwzizp4omzpmnbfgz3zt5pvgeur4wss6@kblfkmtssebw> From: Rick Macklem Date: Sat, 29 Mar 2025 13:04:08 -0700 X-Gm-Features: AQ5f1JrBLw7qN6X9EIEEGSBgAmR2p1EXiGgU-sVe4NfdFL4DWV3xYWTNTJH4xY8 Message-ID: Subject: Re: RFC: Solaris style extended attributes for FreeBSD To: Shawn Webb Cc: Dennis Clarke , freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Queue-Id: 4ZQ7dc2KGJz3Vmy X-Spamd-Bar: ---- On Sat, Mar 29, 2025 at 12:50=E2=80=AFPM Shawn Webb wrote: > > On Sat, Mar 29, 2025 at 12:39:02PM -0700, Rick Macklem wrote: > > > I had added filesystem extended attribute support to libarchive, whic= h > > > is what FreeBSD's tar(1) is based off of. I upstreamed that, so that'= s > > > taken care of. FreeBSD's tar(1) has supported extended attributes > > > since 2020 (see libarchive PR 1409: > > > https://github.com/libarchive/libarchive/pull/1409) > > Ok, thanks for the info. If this stuff goes into FreeBSD, it probably n= eeds > > to be tweaked to use the different syscall API so that it can handle la= rge > > attributes and maybe the attribute's mode. (someday, maybe?) > > I believe libarchive has been updated in FreeBSD since October 2020, > so the vendored libarchive in FreeBSD should already support it. But, > yeah, if FreeBSD makes changes to how extended attributes work, I or > someone else would need to update libarchive to account for that. > > Since HardenedBSD follows FreeBSD closely (we sync every six hours), I > would probably volunteer to update the libarchive code. > > > > Just one data point here: HardenedBSD uses filesystem extended > > > attributes to toggle certain exploit mitigations on a per-application > > > basis. That's why we added support to libarchive: so we can ship > > > certain packages with exploit mitigations pre-toggled. > > Just curious. Does it use "system" or "user" attribute space? > > We use the system namespace, though the userland tool (hbsdcontrol) > was recently taught about the user namespace. The kernel side only > supports system namespace. So the user namespace support in > hbsdcontrol is somewhat meaningless. I do plan to eventually get to > the kernel side, but my TODO list continues growing. :-) Ok, this wouldn't be affected by the patches I've been doing, since they handle user space only. (system space will still work, but only via the extattr_XXX() APIs. rick > > Thanks, > > -- > Shawn Webb > Cofounder / Security Engineer > HardenedBSD > > Tor-ified Signal: +1 303-901-1600 / shawn_webb_opsec.50 > https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/0= 3A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc From nobody Sat Mar 29 20:09:33 2025 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 4ZQ7lj2pWRz5s1TW for ; Sat, 29 Mar 2025 20:09:37 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-il1-x12d.google.com (mail-il1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZQ7lh1f61z3bCp for ; Sat, 29 Mar 2025 20:09:36 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=hardenedbsd.org header.s=google header.b=MKgl5iGR; dmarc=none; spf=pass (mx1.freebsd.org: domain of shawn.webb@hardenedbsd.org designates 2607:f8b0:4864:20::12d as permitted sender) smtp.mailfrom=shawn.webb@hardenedbsd.org Received: by mail-il1-x12d.google.com with SMTP id e9e14a558f8ab-3cfeff44d94so11199655ab.0 for ; Sat, 29 Mar 2025 13:09:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd.org; s=google; t=1743278975; x=1743883775; darn=freebsd.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=h+VXl5mz0k1GbSCFY2Eto1VxqtB+1/Br3trTmhLbR0c=; b=MKgl5iGRVDOkyb/lh2iFHntepZji3fWz+T5kb59ItnCHonIG0Olj5Z3av3PWOEoBQC c5iCQNTLhNiU02+mRMjmtrlkj6DBA90Fdwr0GusZuMvIdriZwrG4onZAngS4r3NiILcW cnf2UgAbdJl9bab5ntWYIneTtjFxEZIwa1rtc5HKySai+FCsQv9a9U+VxSNvmEN2mI5e zeJheHY+QTMjdZ6ANnUU+DAS1iz61+0nDIemChaaHlmSbbpi20DVFeyXX0bE1yz29Xj9 /5ufq0a++PgwR3Qot64gg2kt/vCo4A8Lt8W8a4ZlhezCvI6qgAkukMfO8bVn6xi2yh0M o7Yg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743278975; x=1743883775; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=h+VXl5mz0k1GbSCFY2Eto1VxqtB+1/Br3trTmhLbR0c=; b=qijBWswC100RL5IWxkXPykPa7X1l2mjcjOJTheekg41PuYbO+lYTsSloZSbQbdEr82 +GptQxJxQHgEu9wYzIt+QCfvLWJmkouktkYnZMjkixdd8kSeeOlJDGREiMNtC5SBGUno 8/a/G1TV2N/X9uxx11N0VNVF1gMHbY217qJZ5Ywbo7Ot/xJ7QKUocj/B7kcmIyXNCn6Q Im+HGghVVIpAuekMDX7iXjWIaTPI/CXpLIYBbTuJ9S6leV7XadXjTGO3kPTZzKYcnwdg HIiZjMI1OwIbHRhuFl2FRuEEcGsn82MSycUO4UVU1FCZUN/2WU/WM62sEOSWlaUtMCDH jDEw== X-Forwarded-Encrypted: i=1; AJvYcCXn7G+e+S38KGdsZi1sMOfWrjdDDAyXSUiWUe09+OZWCWOWio5nhrlTllP2wdTLuKq6WcsgtOgLR/F8SZRwZMg=@freebsd.org X-Gm-Message-State: AOJu0YxneDIZdCk1ABQXnKSzinMyWqmi+uZZ7xWBKCflprDg15TijgxB 2U05l2Vsf7lGJ5r8I6c1cSHn+TOnDl7fhjnRBi7QX+n+UcQQAhJ3+SNde7vcYqg= X-Gm-Gg: ASbGncsVnfrWYo3PcHz2FlzQGAVCiGK7I73PRS9WFczkAAQD+l9i/XXr7GC2xkS6v0V rOuR+QZP7zpaJaVZFTwbL0a1q/38b2WCXgcxCN58XndfNyn3k3z1NoDMEJaR5y/Q33n1etC2MiX QDJYnnyZdoa6vrGvvLpSpdEvlub2LuU2uOX+v1GawhJa/d268PnGQvhrAnyUWUrEWExYQuLooOo jIrWGBZfGd8ce+kt7SjmPzjoBwmcII4xm7Z9eamFjUkBXO2Je9BPHPjAAM8r7yxKRqOXnMxAGkB bT0bVKgLAakmy5LSGMdLvLDNz2iiY51oYss4jg== X-Google-Smtp-Source: AGHT+IGEON+vKiEj3vq8jdSEJHWmQ00hTJ0oiDcgaGKGq69QRbMg0XshvDhnivukHzjXQTSjlxE1uw== X-Received: by 2002:a05:6e02:2482:b0:3d0:235b:4810 with SMTP id e9e14a558f8ab-3d5e08f0783mr43723765ab.2.1743278974754; Sat, 29 Mar 2025 13:09:34 -0700 (PDT) Received: from mutt-hbsd ([2001:470:4001:1::95]) by smtp.gmail.com with ESMTPSA id 8926c6da1cb9f-4f464751f00sm1032173173.58.2025.03.29.13.09.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 29 Mar 2025 13:09:34 -0700 (PDT) Date: Sat, 29 Mar 2025 20:09:33 +0000 From: Shawn Webb To: Rick Macklem Cc: Dennis Clarke , freebsd-current@freebsd.org Subject: Re: RFC: Solaris style extended attributes for FreeBSD Message-ID: X-Operating-System: FreeBSD mutt-hbsd 14.2-STABLE-HBSD FreeBSD 14.2-STABLE-HBSD HARDENEDBSD-14-STABLE amd64 X-PGP-Key: https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/blob/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc References: <410014e4-75a6-4923-8f84-3935cab41c31@blastwave.org> <3dso3cojzxnylcfmpmgwzizp4omzpmnbfgz3zt5pvgeur4wss6@kblfkmtssebw> 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: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="iladfedsr74ra2c7" Content-Disposition: inline In-Reply-To: X-Spamd-Result: default: False [-5.09 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.999]; NEURAL_HAM_MEDIUM(-1.00)[-0.997]; NEURAL_HAM_LONG(-1.00)[-0.996]; MID_RHS_NOT_FQDN(0.50)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; R_DKIM_ALLOW(-0.20)[hardenedbsd.org:s=google]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[hardenedbsd.org:+]; RCPT_COUNT_THREE(0.00)[3]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_TO(0.00)[gmail.com]; ARC_NA(0.00)[]; DMARC_NA(0.00)[hardenedbsd.org]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; MISSING_XM_UA(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TAGGED_RCPT(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::12d:from] X-Rspamd-Queue-Id: 4ZQ7lh1f61z3bCp X-Spamd-Bar: ----- --iladfedsr74ra2c7 Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: RFC: Solaris style extended attributes for FreeBSD MIME-Version: 1.0 On Sat, Mar 29, 2025 at 01:04:08PM -0700, Rick Macklem wrote: > On Sat, Mar 29, 2025 at 12:50=E2=80=AFPM Shawn Webb wrote: > > > > On Sat, Mar 29, 2025 at 12:39:02PM -0700, Rick Macklem wrote: > > > > I had added filesystem extended attribute support to libarchive, wh= ich > > > > is what FreeBSD's tar(1) is based off of. I upstreamed that, so tha= t's > > > > taken care of. FreeBSD's tar(1) has supported extended attributes > > > > since 2020 (see libarchive PR 1409: > > > > https://github.com/libarchive/libarchive/pull/1409) > > > Ok, thanks for the info. If this stuff goes into FreeBSD, it probably= needs > > > to be tweaked to use the different syscall API so that it can handle = large > > > attributes and maybe the attribute's mode. (someday, maybe?) > > > > I believe libarchive has been updated in FreeBSD since October 2020, > > so the vendored libarchive in FreeBSD should already support it. But, > > yeah, if FreeBSD makes changes to how extended attributes work, I or > > someone else would need to update libarchive to account for that. > > > > Since HardenedBSD follows FreeBSD closely (we sync every six hours), I > > would probably volunteer to update the libarchive code. > > > > > > Just one data point here: HardenedBSD uses filesystem extended > > > > attributes to toggle certain exploit mitigations on a per-applicati= on > > > > basis. That's why we added support to libarchive: so we can ship > > > > certain packages with exploit mitigations pre-toggled. > > > Just curious. Does it use "system" or "user" attribute space? > > > > We use the system namespace, though the userland tool (hbsdcontrol) > > was recently taught about the user namespace. The kernel side only > > supports system namespace. So the user namespace support in > > hbsdcontrol is somewhat meaningless. I do plan to eventually get to > > the kernel side, but my TODO list continues growing. :-) > Ok, this wouldn't be affected by the patches I've been doing, since they > handle user space only. (system space will still work, but only via the > extattr_XXX() APIs. Cool. I have another project that uses user namespaces: https://git.hardenedbsd.org/shawn.webb/altfs AltFS is a fusefs driver that stores file payload in filesystem extended attributes, using the user namespace. It only partially works and again is bitten by more important items on my TODO list. It mainly serves as a proof-of-concept for a weird data exfiltration technique. Not at all meant for actual production use. Do you already have a patch for review in Phabric? I might want to add myself to it so I can more easily keep informed. Thanks, --=20 Shawn Webb Cofounder / Security Engineer HardenedBSD Tor-ified Signal: +1 303-901-1600 / shawn_webb_opsec.50 https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A= 4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc --iladfedsr74ra2c7 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEA6TL67gupaZ9nzhT/y5nonf44foFAmfoU3YACgkQ/y5nonf4 4fr/Og/8DG/z0p1L9HbivCXVXD2aioV2kZJWOdiMXTHd7xBG9OFcO+uqilvcU3qg rErNz14ntZZNgq4rqydE5igWzaC2+pQo+0Dn5QJ/9LKAYfL8J6G1Z8RTEwD34BFz u95FatLpQw0hC1PM9VAeEV8hOPw+jnVL+LhCo2Xp5koL+ufV7pHRMEG2fllcAIgJ 7E+/qbkcP6x5mv7IxbkdsEWiUMs3WEX4s11Fsk8Mz63g65z8gkejOhFXxAgcLIJS KzOW1LQy4DeLzSBGybbwiQNPUb0YvHqCOcebmVYLAvAP9CyELtkqTwmXrr8lTOgR XrpUdMKyF85bYF4p0vt4rPz+Uop0Qm1PBz4N/nix5gnENNoCA87Ajxp/5sB3e5kF /SieyTn2rGK91Yv1HKXJX1zAkKdNHkCGpV35RIcNBoZDg58w4cleWLgtevhaOT3g TjOeWR6+Px8nO6YvaOjlVKrHen4WY3PnYd0E+zLKv1Of4DXufYDXqQWLIumgefSH HDHQ4fyiAkknMsxRBm2bBVOxJoGEWHgkP8o47wl0KNlTSJhjFZzIJc94/qdmS8a+ 94GxS6WFWGXsXB4+8XEvnn8IvW5hT6iZIMQaa+wRKRyLjA58KMYiL1BsjGPMO67q BUS4ukiXUAB32YlihUB1/WmebQPWeOkzFJWdrkhR2SCCZOlViQk= =mndp -----END PGP SIGNATURE----- --iladfedsr74ra2c7-- From nobody Sat Mar 29 20:22:41 2025 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 4ZQ832236jz5s2KS for ; Sat, 29 Mar 2025 20:22:54 +0000 (UTC) (envelope-from rick.macklem@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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZQ8316KBqz3mDF for ; Sat, 29 Mar 2025 20:22:53 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x532.google.com with SMTP id 4fb4d7f45d1cf-5e5e8274a74so5271907a12.1 for ; Sat, 29 Mar 2025 13:22:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1743279772; x=1743884572; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=FtpQ2pqSMEkUsZVhcjlum8cWPSNcHXLBOFpvTYztLmI=; b=ZhczQulpeIz/1ho/fiOA77oeKfDBSOBWZMqGwSeZeYdkp/mbs5G8l/tFznQkY9OWst 78ZFxs6er5+pUdYGznXjUOP1isaJfU+b+TVxTVB55VXYDXsDVRCHDfYN6Q+LnDDHuCA8 yqK/GjsHqjQM2G1b//QtUfQnv5l0ZORa+kQp+qyxLyynmc1aKLZjFuM9CF+HxrULELaj RT6tDyFB4n0b0g0vP5pAjri+bdggPfjoLP+ed5m0jXSYXz4G6BepfkPy210dJ9FmKfpL CKwp39RohPrcAkSjvDy8SN06MbOyBs4rc/Luuz28rInVtcN/AT8WoIbWZtmSA0V1aYwA gPuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743279772; x=1743884572; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=FtpQ2pqSMEkUsZVhcjlum8cWPSNcHXLBOFpvTYztLmI=; b=CFe4k51t/E5lazghAbQSlnhp2q7I4eetw0kWzVUzefUk+exRjrIxylt6OdmQv07ZKO 2vxldljO1U+nlnDKcqnq+Up0+i2cynTRQEUUCTlu5VEWgFUZdX3B6YjmHwIxa4nXUABF OUaxSI0ELfipNRa8vubruCYHU7iIgk/9pvvSP5lnIUfTvcvkE45YhGg+EXi0EodyJeHY hH2LdPo4MEBX5Dfd0L3E1JN0Xq9YgDK7BK7HizRsodjY9plxIVSZL5JgeqUtj7ptZNk3 jU8pGOxauX2XNVgmY/PWLeNMeCz7Kzpc6rFO3TZHF58KfiF+/GnYLKPe5J/e3wINpO6G g5qw== X-Forwarded-Encrypted: i=1; AJvYcCVr6sdpEG66BfmotGHpcczaEzHuw+yfIsWyMyn4lcOTP9eHNGIR66FpANHvyt4v7jAwt4UqF9B2H3HOZRDridc=@freebsd.org X-Gm-Message-State: AOJu0YxTrCN4nLXtWyyvHO1yw+sjuSR1GNegHSKZdyteotgEef7EyLRb tBwX/lFVLCml9mYPHebQsZXtLy2hDBdqao+ejmPLb7lPITgKPFxoOM1P7URWLfSWpe3MWSs95Bp MV7wOg26X8w++ddmxV/09IbNt2w== X-Gm-Gg: ASbGncvaRN+9lAogLNkqL4P6pDVzfeLxQ9jYPgCBD6pDcd1/1cqEj9PBkFMw5qutvFI F5Nsm3ub0SyUuWKCqpxhkjal0Pd157btzhgxkEq6KsGnxXPUVkqCMmaRC2Q6wqfbegorqKphyuG bgEXC5iRT/RZRKEPFylopELiqfXB4idckAeZsR5Hyqe6N6a54c7rXpjZtSRQ== X-Google-Smtp-Source: AGHT+IHb5OvtS4pJXa6azmoXna7oiPy48zOiOVvrHyHN3xliX5+B0qs7VxdqwSZ9t4knG22jbp5EVAwzBrQEO1XKCQI= X-Received: by 2002:a05:6402:2744:b0:5dc:74fd:abf1 with SMTP id 4fb4d7f45d1cf-5edfd0fd964mr3265040a12.15.1743279772035; Sat, 29 Mar 2025 13:22:52 -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: <410014e4-75a6-4923-8f84-3935cab41c31@blastwave.org> <3dso3cojzxnylcfmpmgwzizp4omzpmnbfgz3zt5pvgeur4wss6@kblfkmtssebw> In-Reply-To: From: Rick Macklem Date: Sat, 29 Mar 2025 13:22:41 -0700 X-Gm-Features: AQ5f1JoTfAb6rjLcagjl-0ALzStOPFWhFJv4Mnm5kKw9XE3KQHOSwQD7W2VWvv0 Message-ID: Subject: Re: RFC: Solaris style extended attributes for FreeBSD To: Shawn Webb Cc: Dennis Clarke , freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Queue-Id: 4ZQ8316KBqz3mDF X-Spamd-Bar: ---- On Sat, Mar 29, 2025 at 1:09=E2=80=AFPM Shawn Webb wrote: > > On Sat, Mar 29, 2025 at 01:04:08PM -0700, Rick Macklem wrote: > > On Sat, Mar 29, 2025 at 12:50=E2=80=AFPM Shawn Webb wrote: > > > > > > On Sat, Mar 29, 2025 at 12:39:02PM -0700, Rick Macklem wrote: > > > > > I had added filesystem extended attribute support to libarchive, = which > > > > > is what FreeBSD's tar(1) is based off of. I upstreamed that, so t= hat's > > > > > taken care of. FreeBSD's tar(1) has supported extended attributes > > > > > since 2020 (see libarchive PR 1409: > > > > > https://github.com/libarchive/libarchive/pull/1409) > > > > Ok, thanks for the info. If this stuff goes into FreeBSD, it probab= ly needs > > > > to be tweaked to use the different syscall API so that it can handl= e large > > > > attributes and maybe the attribute's mode. (someday, maybe?) > > > > > > I believe libarchive has been updated in FreeBSD since October 2020, > > > so the vendored libarchive in FreeBSD should already support it. But, > > > yeah, if FreeBSD makes changes to how extended attributes work, I or > > > someone else would need to update libarchive to account for that. > > > > > > Since HardenedBSD follows FreeBSD closely (we sync every six hours), = I > > > would probably volunteer to update the libarchive code. > > > > > > > > Just one data point here: HardenedBSD uses filesystem extended > > > > > attributes to toggle certain exploit mitigations on a per-applica= tion > > > > > basis. That's why we added support to libarchive: so we can ship > > > > > certain packages with exploit mitigations pre-toggled. > > > > Just curious. Does it use "system" or "user" attribute space? > > > > > > We use the system namespace, though the userland tool (hbsdcontrol) > > > was recently taught about the user namespace. The kernel side only > > > supports system namespace. So the user namespace support in > > > hbsdcontrol is somewhat meaningless. I do plan to eventually get to > > > the kernel side, but my TODO list continues growing. :-) > > Ok, this wouldn't be affected by the patches I've been doing, since the= y > > handle user space only. (system space will still work, but only via the > > extattr_XXX() APIs. > > Cool. I have another project that uses user namespaces: > https://git.hardenedbsd.org/shawn.webb/altfs > > AltFS is a fusefs driver that stores file payload in filesystem > extended attributes, using the user namespace. It only partially works > and again is bitten by more important items on my TODO list. It mainly > serves as a proof-of-concept for a weird data exfiltration technique. > Not at all meant for actual production use. > > Do you already have a patch for review in Phabric? I might want to add > myself to it so I can more easily keep informed. Not yet. I am still cleaning things up and testing. Also, there ahs not been much response related to the question "should this go in FreeBSD?". Dennis doesn't sounds like a "no" and the two posters on freebsd-hackers@ I assume are a"yes", but I haven't heard from anyone else. (Good technical comments, but not related to "should it be in FreeBSD?".) rick > > Thanks, > > -- > Shawn Webb > Cofounder / Security Engineer > HardenedBSD > > Tor-ified Signal: +1 303-901-1600 / shawn_webb_opsec.50 > https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/0= 3A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc From nobody Sat Mar 29 20:46:23 2025 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 4ZQ8ZH4hv0z5s434 for ; Sat, 29 Mar 2025 20:46:31 +0000 (UTC) (envelope-from sgharms@stevengharms.com) Received: from mail-24422.protonmail.ch (mail-24422.protonmail.ch [109.224.244.22]) (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 "protonmail.com", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZQ8ZG4HMNz46jQ for ; Sat, 29 Mar 2025 20:46:30 +0000 (UTC) (envelope-from sgharms@stevengharms.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=stevengharms.com header.s=protonmail header.b=EBB9a0fl; dmarc=none; spf=pass (mx1.freebsd.org: domain of sgharms@stevengharms.com designates 109.224.244.22 as permitted sender) smtp.mailfrom=sgharms@stevengharms.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stevengharms.com; s=protonmail; t=1743281188; x=1743540388; bh=4iKnEOU9zlL8qEKnieh2VU9E7D42Is0kSOKou1VIlvs=; h=Date:To:From:Subject:Message-ID:Feedback-ID:From:To:Cc:Date: Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector: List-Unsubscribe:List-Unsubscribe-Post; b=EBB9a0flf6rAglyKBR0oQ4FVUmSltWXchgJu6GYqu+rSXXoG/CD6MdRRXP2Hqy1Qb SbfsG7nAwdjYehkIaQGtOvh+tDwWL/1b08KWpOoEW69Pxc5Hzr+1KK5SNtGhPfC+m2 auvFWHBqzEQrgqwtrHaISLvAqXx08SRqLK+zPwKs= Date: Sat, 29 Mar 2025 20:46:23 +0000 To: "freebsd-current@freebsd.org" From: "Steven Harms (High-Security Mail)" Subject: Kernel panic on HEAD (93cf4310 2025-03-28) Message-ID: Feedback-ID: 16996530:user:proton X-Pm-Message-ID: 612cdb8b1ccb7cb0fdd8db87f14e8ecc0c11c82e 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: multipart/alternative; boundary="b1=_LU6RsEEvPxM01r1j1batMP5jR2MYIgm3S8yU5blgA8" X-Spamd-Result: default: False [-4.35 / 15.00]; RBL_SENDERSCORE_REPUT_9(-1.00)[109.224.244.22:from]; NEURAL_HAM_SHORT(-1.00)[-0.996]; NEURAL_HAM_MEDIUM(-0.99)[-0.987]; NEURAL_HAM_LONG(-0.96)[-0.963]; R_SPF_ALLOW(-0.20)[+ip4:109.224.244.0/24]; R_DKIM_ALLOW(-0.20)[stevengharms.com:s=protonmail]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; MIME_BASE64_TEXT(0.10)[]; MISSING_XM_UA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCPT_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:29676, ipnet:109.224.244.0/22, country:GB]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; DMARC_NA(0.00)[stevengharms.com]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_ZERO(0.00)[0]; TO_DN_EQ_ADDR_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@FreeBSD.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[stevengharms.com:+] X-Rspamd-Queue-Id: 4ZQ8ZG4HMNz46jQ X-Spamd-Bar: ---- --b1=_LU6RsEEvPxM01r1j1batMP5jR2MYIgm3S8yU5blgA8 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SGV5IGZvbGtzLAoKSSB0cmllZCBidWlsZGluZyBjdXJyZW50IGZyb20gc291cmNlIGFuZCB3aGVu IEkgYm9vdCwgSSBnZXQgYSBwYW5pYyBhZnRlciB0aGUgZmluYWwgQXV0b2xvYWRpbmcgbW9kdWxl IChwY2h0aGVybSwgaW4gbXkgY2FzZSkgbG9hZHMuIENvbXBhcmluZyB0byB0aGUgc3RhYmxlIDE0 LjIga2VybmVsLCB0aGUgbmV4dCBzdGVwIGlzIGZvciAiU2V0dGluZyB1cCBoYXJ2ZXN0aW5nLCIg IkZlZWRpbmcgZW50cm9weSwiIGFuZCBzdGFydGluZyB3cGFfc3VwcGxpY2FudC4KClRvIGJlIGNs ZWFyLCB0aGlzIGNvbW1pdCBpcyBub3QgdGhlIHRoaW5nIHRoYXQgYnJva2UgdGhpbmdzLgoKSW4g cHVyc3VpdCBvZiBnZXR0aW5nIG1vcmUgZGF0YSwgSSdtIHRyeWluZyB0byBpc29sYXRlIHR3byBx dWVzdGlvbnM6CgotIFdoeSBhbSBJIG5vdCBnZXR0aW5nIGFueSBwYW5pYyBkdW1wIGFydGlmYWN0 cz8KLSBEaWQgSSBidWlsdCBjdXJyZW50IGZyb20gSEVBRCBwcm9wZXJseT8KCkluIGVmZm9ydCB0 byBnZXQgbW9yZSBkYXRhLCBJJ20gZm9sbG93aW5nOiBodHRwczovL2RvY3MuZnJlZWJzZC5vcmcv ZW4vYm9va3MvZGV2ZWxvcGVycy1oYW5kYm9vay9rZXJuZWxkZWJ1Zy8KCi0gQ29uZmlybSB0aGF0 IC9ldGMvcmMuY29uZiBoYXMgZHVtcGRldiBzZXQgdG8gQVVUTwotIEJvdGggL2V0Yy9mc3RhYiBh bmQgc3dhcCBpbmZvIGNvbmZpcm0gdGhhdCAvZGV2L2FkYTBwMyBpcyBjb25maWd1cmVkIGZvciBz d2FwLiBJdCBpcyBhbHNvIHRoZSBvbmx5IGRldmljZS4gVGhlcmVmb3JlIEkgZXhwZWN0IGR1bXBl ZCB0byB3cml0ZSB0byB0aGF0IGRldmljZQotIFlldCBkZXNwaXRlIHRoZSBrZXJuZWwgcGFuaWNr aW5nLCB0aGVyZSdzIG5vdGhpbmcgaW4gdGhhdCBkaXJlY3RvcnkgZXhjZXB0IGZpbGUgIm1pbmZy ZWUiIHdoaWNoIHNheXMgIjIwNDgiIGluIGl0LgotIEkgbWFudWFsbHkgc2V0IGR1bXBkaXIgdG8g Ii92YXIvY3Jhc2giIHdoaWNoIGhhcyA3NTAgcGVybWlzc2lvbnMgYW5kIHRyeSB0byBib290IHRo ZSBuZXcga2VybmVsOyBwYW5pYzsgYm9vdCBpbnRvIHN0YWJsZSBrZXJuZWwgYW5kLi4ubm90aGlu ZyBpbiAvdmFyL2NyYXNoIGV4Y2VwdCBtaW5mcmVl4oCLCgpOb3csIEknbSBzdGlsbCB2ZXJ5IG5l dyB0byBidWlsZGluZyBDVVJSRU5ULCBidXQgSSd2ZSBiZWVuIGZvbGxvd2luZzoKCmh0dHBzOi8v ZG9jcy5mcmVlYnNkLm9yZy9lbi9ib29rcy9oYW5kYm9vay9jdXR0aW5nLWVkZ2UvI3VwZGF0aW5n LXNyYy1xdWljay1zdGFydAoKIyBldGN1cGRhdGUgZXh0cmFjdCAoMSkKIyBldGN1cGRhdGUgZGlm ZiAoMikKIyBnaXQgcHVsbCAtQyAvdXNyL3NyYyAoMSkKY2hlY2sgL3Vzci9zcmMvVVBEQVRJTkcg KDIpCiMgY2QgL3Vzci9zcmMgKDMpCiMgbWFrZSAtajQgYnVpbGR3b3JsZCAoNCkKIyBtYWtlIC1q NCBrZXJuZWwgKDUpIyBzaHV0ZG93biAtciBub3cgKDYpCgpBbmQgYW0gYWZ0ZXIgdGhlIHNodXRk b3duIC1yIG5vd+KAiyBzdGVwOgoKSWYgbXkgcHJvY2VzcyBmb3Iga2VybmVsIGFuZCB3b3JsZCBi dWlsZCBpcyBjb3JyZWN0LCB0aGVuIEkgaGF2ZSBmb3VuZCBhIHBhbmljLiBIb3cgY2FuIEkgaGVs cC9kZWJ1Zz8KClRoYW5rcyEKClN0ZXZlbgoKLS0tCgpQdWJsaWMgS2V5OiAyMkJFMzlFMkZBNjhE OEJBOERDNEI0M0E1NUExNkQ4Q0UyQjAzNkRFCgpNZXNzYWdlcyBmcm9tIHRoaXMgYWNjb3VudCBh cmUgY29uc2lkZXJlZCB0aGUgYmVzdC1zZWN1cmVkIGFuZCBtb3N0IHJlbGlhYmxlLiBTZW5kIGlu Zm9ybWF0aW9uIHJlZ2FyZGluZyBoZWFsdGgsIHdlYWx0aCwgb3IgcmVxdWlyaW5nIGhpZ2hlciBz dGFuZGFyZHMgb2Ygc2VjdXJpdHkgdG8gdGhpcyBhZGRyZXNzLgoKU2VudCB3aXRoIFtQcm90b24g TWFpbF0oaHR0cHM6Ly9wcm90b24ubWUvbWFpbC9ob21lKSBzZWN1cmUgZW1haWwu --b1=_LU6RsEEvPxM01r1j1batMP5jR2MYIgm3S8yU5blgA8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0 cHg7Ij5IZXkgZm9sa3MsPC9kaXY+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5z LXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij48YnI+PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1mYW1p bHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij5JIHRyaWVkIGJ1aWxkaW5n IGN1cnJlbnQgZnJvbSBzb3VyY2UgYW5kIHdoZW4gSSBib290LCBJIGdldCBhIHBhbmljIGFmdGVy IHRoZSBmaW5hbCBBdXRvbG9hZGluZyBtb2R1bGUgKHBjaHRoZXJtLCBpbiBteSBjYXNlKSBsb2Fk cy4gQ29tcGFyaW5nIHRvIHRoZSBzdGFibGUgMTQuMiBrZXJuZWwsIHRoZSBuZXh0IHN0ZXAgaXMg Zm9yICJTZXR0aW5nIHVwIGhhcnZlc3RpbmcsIiAiRmVlZGluZyBlbnRyb3B5LCIgYW5kIHN0YXJ0 aW5nIHdwYV9zdXBwbGljYW50LjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwg c2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+PGJyPjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQt ZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+VG8gYmUgY2xlYXIs IHRoaXMgY29tbWl0IGlzIG5vdCB0aGUgdGhpbmcgdGhhdCBicm9rZSB0aGluZ3MuPC9kaXY+PGRp diBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7 Ij48YnI+PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBm b250LXNpemU6IDE0cHg7Ij5JbiBwdXJzdWl0IG9mIGdldHRpbmcgbW9yZSBkYXRhLCBJJ20gdHJ5 aW5nIHRvIGlzb2xhdGUgdHdvIHF1ZXN0aW9uczo8L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWls eTogQXJpYWwsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPjxicj48L2Rpdj48ZGl2IHN0 eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPjxv bCBkYXRhLWVkaXRpbmctaW5mbz0ieyZxdW90O29yZGVyZWRTdHlsZVR5cGUmcXVvdDs6MSwmcXVv dDt1bm9yZGVyZWRTdHlsZVR5cGUmcXVvdDs6MX0iIHN0eWxlPSJtYXJnaW4tdG9wOiAwcHg7IG1h cmdpbi1ib3R0b206IDBweDsiIGRhdGEtbGlzdGNoYWluPSJfX0xpc3RfQ2hhaW5fMjIxIj48bGkg c3R5bGU9Imxpc3Qtc3R5bGUtdHlwZTogJnF1b3Q7MS4gJnF1b3Q7OyI+V2h5IGFtIEkgbm90IGdl dHRpbmcgYW55IHBhbmljIGR1bXAgYXJ0aWZhY3RzPzwvbGk+PGxpIHN0eWxlPSJsaXN0LXN0eWxl LXR5cGU6ICZxdW90OzIuICZxdW90OzsiPkRpZCBJIGJ1aWx0IGN1cnJlbnQgZnJvbSBIRUFEIHBy b3Blcmx5PzwvbGk+PC9vbD48L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNh bnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPjxicj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZh bWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPkluIGVmZm9ydCB0byBn ZXQgbW9yZSBkYXRhLCBJJ20gZm9sbG93aW5nOiZuYnNwOzxzcGFuPjxhIHRhcmdldD0iX2JsYW5r IiByZWw9Im5vcmVmZXJyZXIgbm9mb2xsb3cgbm9vcGVuZXIiIGhyZWY9Imh0dHBzOi8vZG9jcy5m cmVlYnNkLm9yZy9lbi9ib29rcy9kZXZlbG9wZXJzLWhhbmRib29rL2tlcm5lbGRlYnVnLyI+aHR0 cHM6Ly9kb2NzLmZyZWVic2Qub3JnL2VuL2Jvb2tzL2RldmVsb3BlcnMtaGFuZGJvb2sva2VybmVs ZGVidWcvPC9hPjwvc3Bhbj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNh bnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPjxicj48L2Rpdj48ZGl2PjxvbCBkYXRhLWVkaXRp bmctaW5mbz0ieyZxdW90O29yZGVyZWRTdHlsZVR5cGUmcXVvdDs6MSwmcXVvdDt1bm9yZGVyZWRT dHlsZVR5cGUmcXVvdDs6MX0iIHN0eWxlPSJtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206 IDBweDsiIGRhdGEtbGlzdGNoYWluPSJfX0xpc3RfQ2hhaW5fMjIyIj48bGkgc3R5bGU9Imxpc3Qt c3R5bGUtdHlwZTogJnF1b3Q7MS4gJnF1b3Q7OyI+PGZvbnQgZmFjZT0iQXJpYWwsIHNhbnMtc2Vy aWYiPkNvbmZpcm0gdGhhdCAvZXRjL3JjLmNvbmYgaGFzIGR1bXBkZXYgc2V0IHRvIEFVVE88L2Zv bnQ+PC9saT48bGkgc3R5bGU9Imxpc3Qtc3R5bGUtdHlwZTogJnF1b3Q7Mi4gJnF1b3Q7OyI+PGZv bnQgZmFjZT0iQXJpYWwsIHNhbnMtc2VyaWYiPkJvdGggL2V0Yy9mc3RhYiBhbmQgc3dhcCBpbmZv IGNvbmZpcm0gdGhhdCAvZGV2L2FkYTBwMyBpcyBjb25maWd1cmVkIGZvciBzd2FwLiBJdCBpcyBh bHNvIHRoZSBvbmx5IGRldmljZS4gVGhlcmVmb3JlIEkgZXhwZWN0IGR1bXBlZCB0byB3cml0ZSB0 byB0aGF0IGRldmljZTwvZm9udD48L2xpPjxsaSBzdHlsZT0ibGlzdC1zdHlsZS10eXBlOiAmcXVv dDszLiAmcXVvdDs7Ij48Zm9udCBmYWNlPSJBcmlhbCwgc2Fucy1zZXJpZiI+WWV0IGRlc3BpdGUg dGhlIGtlcm5lbCBwYW5pY2tpbmcsIHRoZXJlJ3Mgbm90aGluZyBpbiB0aGF0IGRpcmVjdG9yeSBl eGNlcHQgZmlsZSAibWluZnJlZSIgd2hpY2ggc2F5cyAiMjA0OCIgaW4gaXQuPC9mb250PjwvbGk+ PGxpIHN0eWxlPSJsaXN0LXN0eWxlLXR5cGU6ICZxdW90OzQuICZxdW90OzsiPjxmb250IGZhY2U9 IkFyaWFsLCBzYW5zLXNlcmlmIj5JIG1hbnVhbGx5IHNldCBkdW1wZGlyIHRvICIvdmFyL2NyYXNo IiB3aGljaCBoYXMgNzUwIHBlcm1pc3Npb25zIGFuZCB0cnkgdG8gYm9vdCB0aGUgbmV3IGtlcm5l bDsgcGFuaWM7IGJvb3QgaW50byBzdGFibGUga2VybmVsIGFuZC4uLm5vdGhpbmcgaW4gL3Zhci9j cmFzaCBleGNlcHQgPGNvZGU+bWluZnJlZTwvY29kZT7igIs8L2ZvbnQ+PC9saT48L29sPjwvZGl2 PjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAx NHB4OyI+PGJyPjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJp ZjsgZm9udC1zaXplOiAxNHB4OyI+Tm93LCBJJ20gc3RpbGwgdmVyeSBuZXcgdG8gYnVpbGRpbmcg Q1VSUkVOVCwgYnV0IEkndmUgYmVlbiBmb2xsb3dpbmc6PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1m YW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij48YnI+PC9kaXY+PGRp diBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7 Ij48c3Bhbj48YSB0YXJnZXQ9Il9ibGFuayIgcmVsPSJub3JlZmVycmVyIG5vZm9sbG93IG5vb3Bl bmVyIiBocmVmPSJodHRwczovL2RvY3MuZnJlZWJzZC5vcmcvZW4vYm9va3MvaGFuZGJvb2svY3V0 dGluZy1lZGdlLyN1cGRhdGluZy1zcmMtcXVpY2stc3RhcnQiPmh0dHBzOi8vZG9jcy5mcmVlYnNk Lm9yZy9lbi9ib29rcy9oYW5kYm9vay9jdXR0aW5nLWVkZ2UvI3VwZGF0aW5nLXNyYy1xdWljay1z dGFydDwvYT48L3NwYW4+PGJyPjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwg c2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+PGJyPjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQt ZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+PHNwYW4+IyBldGN1 cGRhdGUgZXh0cmFjdCAoMSk8L3NwYW4+PGRpdj48c3Bhbj4jIGV0Y3VwZGF0ZSBkaWZmICgyKTwv c3Bhbj48L2Rpdj48ZGl2PjxzcGFuPiMgZ2l0IHB1bGwgLUMgL3Vzci9zcmMgJm5ic3A7KDEpPC9z cGFuPjwvZGl2PjxkaXY+PHNwYW4+Y2hlY2sgL3Vzci9zcmMvVVBEQVRJTkcgJm5ic3A7KDIpPC9z cGFuPjwvZGl2PjxkaXY+PHNwYW4+IyBjZCAvdXNyL3NyYyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7KDMpPC9zcGFuPjwvZGl2PjxkaXY+PHNwYW4+IyBtYWtlIC1qNCBidWlsZHdv cmxkICZuYnNwOyg0KTwvc3Bhbj48L2Rpdj48ZGl2PjxzcGFuPiMgbWFrZSAtajQga2VybmVsICZu YnNwOyAmbmJzcDsgJm5ic3A7KDUpPC9zcGFuPjwvZGl2PjxzcGFuPiMgc2h1dGRvd24gLXIgbm93 ICZuYnNwOyAmbmJzcDsgJm5ic3A7KDYpPC9zcGFuPjxicj48L2Rpdj48ZGl2IHN0eWxlPSJmb250 LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPjxicj48L2Rpdj48 ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRw eDsiPkFuZCBhbSBhZnRlciB0aGUgPGNvZGU+c2h1dGRvd24gLXIgbm93PC9jb2RlPuKAiyBzdGVw OjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsgZm9udC1z aXplOiAxNHB4OyI+PGJyPjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fu cy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+SWYgbXkgcHJvY2VzcyBmb3Iga2VybmVsIGFuZCB3 b3JsZCBidWlsZCBpcyBjb3JyZWN0LCB0aGVuIEkgaGF2ZSBmb3VuZCBhIHBhbmljLiBIb3cgY2Fu IEkgaGVscC9kZWJ1Zz88L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMt c2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPjxicj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWls eTogQXJpYWwsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPlRoYW5rcyE8L2Rpdj48ZGl2 IHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsi Pjxicj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IGZv bnQtc2l6ZTogMTRweDsiPlN0ZXZlbjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlh bCwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+PGJyPjwvZGl2Pg0KPGRpdiBjbGFzcz0i cHJvdG9ubWFpbF9zaWduYXR1cmVfYmxvY2siIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNh bnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KICAgIDxkaXYgY2xhc3M9InByb3Rvbm1haWxf c2lnbmF0dXJlX2Jsb2NrLXVzZXIiPg0KICAgICAgICA8ZGl2Pi0tLTxicj48L2Rpdj48ZGl2Pjxi cj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IGZvbnQt c2l6ZTogMTRweDsgY29sb3I6IHJnYigwLCAwLCAwKTsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1 NSwgMjU1LCAyNTUpOyI+UHVibGljIEtleTogPGEgdGl0bGU9IjIyQkUzOUUyRkE2OEQ4QkE4REM0 QjQzQTU1QTE2RDhDRTJCMDM2REUiIGhyZWY9Imh0dHBzOi8vMjJCRTM5RTJGQTY4RDhCQThEQzRC NDNBNTVBMTZEOENFMkIwMzZERSI+PHNwYW4+MjJCRTM5RTJGQTY4RDhCQThEQzRCNDNBNTVBMTZE OENFMkIwMzZERTwvc3Bhbj48L2E+PGJyPjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtc3R5bGU6IG5v cm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1p bmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdv cmQtc3BhY2luZzogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IGZvbnQtZmFtaWx5OiBBcmlh bCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDM0LCAzNCwgMzQpOyI+PGJyPjwv ZGl2PjxkaXY+TWVzc2FnZXMgZnJvbSB0aGlzIGFjY291bnQgYXJlIGNvbnNpZGVyZWQgdGhlIGJl c3Qtc2VjdXJlZCBhbmQgbW9zdCByZWxpYWJsZS4gU2VuZCBpbmZvcm1hdGlvbiByZWdhcmRpbmcg aGVhbHRoLCB3ZWFsdGgsIG9yIHJlcXVpcmluZyBoaWdoZXIgc3RhbmRhcmRzIG9mIHNlY3VyaXR5 IHRvIHRoaXMgYWRkcmVzcy48YnI+PC9kaXY+DQogICAgPC9kaXY+DQogICAgPGRpdiBzdHlsZT0i Zm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij48YnI+PC9k aXY+DQogICAgPGRpdiBjbGFzcz0icHJvdG9ubWFpbF9zaWduYXR1cmVfYmxvY2stcHJvdG9uIj4N CiAgICAgICAgU2VudCB3aXRoIDxhIHRhcmdldD0iX2JsYW5rIiBocmVmPSJodHRwczovL3Byb3Rv bi5tZS9tYWlsL2hvbWUiPlByb3RvbiBNYWlsPC9hPiBzZWN1cmUgZW1haWwuDQogICAgPC9kaXY+ DQo8L2Rpdj4NCg== --b1=_LU6RsEEvPxM01r1j1batMP5jR2MYIgm3S8yU5blgA8-- From nobody Sun Mar 30 13:24:23 2025 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 4ZQZjn3j9yz5rR2K for ; Sun, 30 Mar 2025 13:24:29 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [IPv6:2a00:1450:4864:20::32e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZQZjm4ySDz3ZDH for ; Sun, 30 Mar 2025 13:24:28 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=SetxyLRS; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of grahamperrin@gmail.com designates 2a00:1450:4864:20::32e as permitted sender) smtp.mailfrom=grahamperrin@gmail.com Received: by mail-wm1-x32e.google.com with SMTP id 5b1f17b1804b1-43cf034d4abso41781265e9.3 for ; Sun, 30 Mar 2025 06:24:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1743341067; x=1743945867; darn=freebsd.org; h=content-transfer-encoding:in-reply-to:autocrypt:content-language :from:references:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=3yPOEA/VeI8OfeqqcHNb7KIX5LNkoZg9sVVPorOZ3iE=; b=SetxyLRSIBMLjicrU6FeqbiwXFamJqJXMS1O1mUbzGqXYO0ekNdXZpE2yMQXEVwdtp aSGyNO5sSFwCgB+LVCJ7+75B8ATd1ZE+WPecivdG4YSFI405wNaOB7ldCZVyZoHDDjeW Kcll9hT7tv54cFC4j+FNkyC+YW/Bxbvpf5Pqbvi4Xb3pWScR38Si7u5BmyWK2hZut4u0 aOovZsiRXlvelnwVsnvciYWd6nPYvE/iEzA30diyfmwE/k6LeN4jL8KtaPpIOxFgILm+ yRZmdPLrGyK9t2IwhyBoT+d8b1/jUjN5rEloQ0dp2ufDM4Vb5OL3FdeXKzrma+wkE1Ih bfqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743341067; x=1743945867; h=content-transfer-encoding:in-reply-to:autocrypt:content-language :from:references:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=3yPOEA/VeI8OfeqqcHNb7KIX5LNkoZg9sVVPorOZ3iE=; b=pyU+llla6VGfozNS1veB7p7RYVk2m0INOIr3wfv4EOwLqws1t+RSVkwpPMgAGrBp68 q07Da/WgMhXPTpy0k1jQIJ6ZLOvOEHXuM7yS5iRsDCZJnHHe5UtHzi3SBH8Q64nrx4ia 0P6iAdi1GUS2RLOO5GhxX1tb95X39SfCqWllaU3JegBiZ1Ert5aEjWSZ85sephcH4dtS w9rrkOTBTTgkXmhpLBF7HkY/BX8MVpvgc5UkoDe1MdzwpiH9xhk4zWy7GzUANmYn2wX3 bGWgTLgvPUgGxuM/jAJKFOLeTFGbNGa5j4HGY54D+OYl/gMtgvbDWsmGsSlBBXJlQUgK +Qtg== X-Gm-Message-State: AOJu0Yx77ZsfA6jD9dx7PbxM7IpFOK5/Rb96fPEYe20SJyzzpIyKDTKS CH0+A1IdPaDvIdlWVSIzAHVN2R9vWsReEr968TRSKqW9f1P/pJD92qptgw== X-Gm-Gg: ASbGnctIwlBPBWr6UeV2TdBPWMXFhC0bxsWw2ITIZUaBXyr0GLmhaOM5K2B6vnnahHf ZtgdQivMC6cT7MD+Yfvfz4ZqV5rzLjpzW5foh7oolmnTuvIiJoPmqlF7jB/19Je5CQQMpXhMVaE t8pqh5d4Reh4M+JCmMd/kWF94/VfvUTD3ZtmZjYDSQGSgSlDsfI9kExONb6ItwXuIuYKiSFcnkx UeS8PPEXWHmStlGkX8K5cu420XPvIWymfQKWntg/sl896wGwFMU1a+WTiuPfGiE4qeA1nlRBI2d NCmlAv30tOhIBz1GJ6ktixLbYST+Wh+JRApQXkyBbAsnEMaGf8z0EIjtYCLDNH9LJYf26gNpYOE AQw== X-Google-Smtp-Source: AGHT+IGnXTPKK1lbBbgOGbHbMj+12O/aVaKBIb+DHFUTKRO8Ybj3GJQgZm7EZnX9sDky+jw9guvUfA== X-Received: by 2002:a05:600c:4593:b0:43c:e7a7:aea0 with SMTP id 5b1f17b1804b1-43dbc6f7b3fmr40121515e9.26.1743341066401; Sun, 30 Mar 2025 06:24:26 -0700 (PDT) Received: from [192.168.1.10] (host-78-150-77-46.as13285.net. [78.150.77.46]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-43d8ff02f84sm91555225e9.25.2025.03.30.06.24.25 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 30 Mar 2025 06:24:25 -0700 (PDT) Message-ID: Date: Sun, 30 Mar 2025 14:24:23 +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 Thunderbird Subject: =?UTF-8?Q?/var/crash/vmcore=2E*_not_present_=28was=3A_Kernel_panic_?= =?UTF-8?B?b24gSEVBRCDigKYp?= To: freebsd-current@freebsd.org References: From: Graham Perrin Content-Language: en-GB Autocrypt: addr=grahamperrin@gmail.com; keydata= xsFNBGKYt7ABEAClu83dJ3ZKfVgPOk9YKRv0Z+dl2b88+k9R4vwAmElgguYdKE7yhnQNhhWM v9vi6AFrBMc2oJdVHJ2OrXfwpELBFIgiSMEWNsC4e+Z3HtSajcl+pFZsP7ciiSoycj/w3wIV kAZoVGbhyIbNG7fbCEJ8q81TbfsGypV3bRmbZVvGNecBguYiooBtz2Qht1p3itXMkIA6P9pS YDl+6QddZLyUUAjAnFv2QDoYSHLnaDUWw4oONZsB0SKVu8jMIBh4uJZoYEOvdvc9jQQdOpA2 CAgA6ulfm42Ikr9lKBUUCtjqiWAhJ7iXOTyHAIdR4Mf8alCE6tdTq6dHdIt+GktTY7oYNyL2 3aD3C7I5waU0SFXvJcOMG10QLfwYQMOQoYQ9XJ0U5A28WYiDcylDdUWT7SappP1e1ZMeJWWO y14mxxNzHaJSI4rK8P/p5tp3Q7SSC4k5gMh9zKba3K2ApCWNbVLGvXsJeQkZZNvu70tE81ey AHI5iZcB6D7WaHysBUmsKaEpbcmm1ZThTnGL0SHEl5to5Jab5Fg6O+Cnly5sVz5lX/v8Aosx kKNei7SCVqXOVtteQeGxWbXWbhPgbMyc0Gi3DuxBI/yvJ43k/rJysQlLGLWfJx/UXprwLluC PDK9EvKEB+fD1Z349uzp1sKr3ihpySbyKI8fpudftnAz4EsoCwARAQABzSZHcmFoYW0gUGVy cmluIDxncmFoYW1wZXJyaW5AZ21haWwuY29tPsLBlAQTAQoAPhYhBFk/5bLDBwftvJcvCrdn SG9KGNQLBQJimMMBAhsDBQkFo5qABQsJCAcDBRUKCQgLBRYDAgEAAh4FAheAAAoJELdnSG9K GNQLbHAQAJi998y42bEbq5HmABYovmAEtQj33YSUWyc9QRmAHpN8Er3lTKsgmZcVChB5Fu/d go2oYynDjlVpA7+wiSmg4AG78mOYbg/e19XMhrH0keDKqZXFkU+G7agR0mF09qvpQZ9MTJYZ 2u7FtytZK665UfipOdV8eGn2hFC/WynjUwEzKyryBgbbLAEbfOPeZNry4h2ZPWbtTvx/PE/V X3Vh2oGqYx69DCGz+0xEhy62ZKbkX5SL8LUf/1WViyCVzsHasFxmFxYPWIfBy8ayQ7xapz7M cSXSQyu4oDT4qh9eZiGP9/aAcZKHcV6t9y77JGhUJ/5O1sANKMa3YhgimE+Z86LHYa1IH774 PHj1nAXBwS+Cj/1l/NQoQcyjvOj8zuCsMJVaLMb6B46YsReP4+3yBLpyeBC//t6zWPbgAkWW VjROC0dXUAMTFpnA6NZe3UghG+Nc4fnCLGOhc2nyWFYHIaYV6Hv1ITFSem9DdeNnR1CFm1VM TJ7i7TuqYM+WZTkoUsTf4c46hS/ZNJZSCxh0s9yYr+BYk3XBbd+ElaZ1dJE6cuSVdw15+P2h DnprurxC4byl4YFkn+UAVvQsOgeq6aSHLOHX0weYu1OLoiPYsTdyGhne72+kDhEEdFD5aHdQ PFrbQIrqWLV0a04++0ZwGpNvXtgnWhDdAQJDwGsSSwbLzsFNBGKYt7ABEADRb1tZuh7DPYET 0wK6fe7owbYgM+RfKhmcrGgR2HI9M2q6+0WKF/ITnggWdIW2Ecc4z2boLz/cwvPGCS7/YxZM 61KklGCwuS7q1s04XnHDWHuFxfXQPzAdVmNO3bYoMZbJjHXs6sB2u5ksiwPwaMAWWaGkviSj c5pwvHCiTmX5vH5CBj/Vi+5ESyX38vK4JM5S/m4ouI/6M9biyFgimV+v3vVyCxJCT1gI9g4o GIh1qq5S433b1fihn4yHPf8XOKyBpA/QcwLONViBqJL5nnOxpsh344rNxn2R7CcRzzicOV+e 2IbMem4lwNWQlZKoRotKXZi9LqN5mynSBYqAUdoZum0QinWT9F22B0Qex5PH1zAt9i2W91Vd kcPB3LwkRXj07ycRtsSzpgPA6fLc6AsoWFslHl8kVOO5eJIA4xhjlPa+W8lguQHZ0iX+5uAv 2eAgXR2swADuHPuENNFStmsgAMl8OOOgtq75yA5TpyIzxMuXV9Nmp0VfIaUM/IdLdmxhc1pC c320l5fYMHVLFAReWEbSj2QH8YzWfpXHIegutWWYEbH9SiDXgS9KoKmCJV/Qa+x6/b8y3pOZ vnIbCDaynC2Yr50s8gRa9kb54JE8Z+p8r16U3SEsK3PtUi0RF0e51danCVHrrE6/Hat2XUO/ 6nnYgVgFOrLao6Gh/VMs8wARAQABwsF8BBgBCgAmFiEEWT/lssMHB+28ly8Kt2dIb0oY1AsF AmKYt7ACGwwFCQWjmoAACgkQt2dIb0oY1Av7qg//YjCZg8VXyMzXssgIQpROKKqh5V0UBSQl rM3tq4tWhyg0HVMugQj0Om+iNPsEEOGHkm6tyhHMzlKGpAc/l0iAM+8twIyg44Yo5+DcfFXr OMTbTw9T9jDsWOkOBksxy29iYhgpqpWdDBnhXvrJp/FNAiX8CfzrIOZeFPydDoEiKBEXAxfe a9o5J/JeVnZiUeoiFe7i68nZGsb4JxhPczNfqW12t0Ll5/ibjszg5BgjXiLao0KqbWNh4bS5 CVwH90Or+5qqWgzWPeBiuz+rN2QXE/V/fL44GEj1YKASCqmaiYRgjoRFubz1aq1wCXMXY3Iq d4525rscUgS7HBxbblnyTodUPaamN/2nSzcmE/Pkx8MApDSgZCIhs0RTAg+/AoX4HULV1rSE TQwMrBEQt84Tw5W5rHsvXKr4ZEsJUpbPLWYTISsp23nHR+vZtL/Ug+OWCmHC7X7D21xk/xVJ 4sA1RLJBKdCHtnyA4Unv/kNS1KVGxHnITVyw1a71QJADu4qsdtM5u6CyYUhqhM1oseWtV6j+ Qi8KC/G4C3AgZf06fe2fVl42z2grTabL4bC6FQXMwTX2dsm5NakWjUCmUL8uwsQE7ZA4zKxo EYI1YV9q1birpzncYRupr1qnMoggMUHWq0IBYshFQrEO8PeVUZBw7/GfAeh3argdw2Qu748T Cyw= In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Result: default: False [-0.39 / 15.00]; NEURAL_SPAM_LONG(1.00)[1.000]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.32)[-0.324]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_MEDIUM(-0.07)[-0.070]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; FROM_HAS_DN(0.00)[]; FREEFALL_USER(0.00)[grahamperrin]; TO_DN_NONE(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::32e:from] X-Rspamd-Queue-Id: 4ZQZjm4ySDz3ZDH X-Spamd-Bar: / On 29/03/2025 20:46, Steven Harms (High-Security Mail) wrote: > > … two questions: > > 1. Why am I not getting any panic dump artifacts? > 2. … > > geli list or (with the port) lsblk /dev/ada0 From nobody Sun Mar 30 20:35:11 2025 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 4ZQmH70TkNz5s2XL for ; Sun, 30 Mar 2025 20:35:31 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-21.consmr.mail.gq1.yahoo.com (sonic305-21.consmr.mail.gq1.yahoo.com [98.137.64.84]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZQmH426Hmz3Tvg for ; Sun, 30 Mar 2025 20:35:28 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=XX1GQ31Q; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1743366926; bh=O6C8QwBuRaovQ9Ld6QrDOpNDiSyOV9GnbLiL+X4Gbow=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=XX1GQ31QT7kYW0Oen0BuESnE6ueEp1PA9kCBnaU6Qr09LUpmP+OkMOd9bXVCbzXOGPyoAeslsLqk6I4E4Bd74Bz7KjsMpqxjVywznupf6tCigspCSsVouTw58Ok4RPnliGlqjf0qqiA8tNsrg/7aOIABfTUdVzImH+N0q9bii6toeCP0eHltr2j1pY8iqD4GRd5Db07rfh2obdungXr05m/w0u1Jw6kshe02AycapXqEkpYfKOeZP6x5UTUcPkzqBd8ZeLR/HzJYy4IubHhEpfVLbTYZWNkke5DfaXPnwgBQjIXWE8444CEi7Pk+jXkPdD8dffKD41TDsqmy8Yb3iA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1743366926; bh=q3FKzSlnnrScGa9HRpI1ODkCLhfsUjtcAHqXyrSwbQL=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=TKuQFyn9lCc79Iv5zQAhti2qYpF6GKyuNkWhWt8ymbysXHS9MWgqmyFSo5NSGF/wxSJlozee3/tx7rRdmP+7lndRK5Ic2/GjIUPPMnFUdxklecmMHtz5BX+TuLUfI3A0+PqKn5z1kYsYautnuA97Dbn+aKMQCX4zt+/zF0vdn6wu+uhqyHf/weMqwR0clF1xll+bH8H56V9KDSTOA3gg0rV1ujFrI0Z3FZ+yUJBOXfhwYimoxUz+3HEFvuuPVB7NaID1sUQ2f6K4KPMB9dwjMakeBPUaBzLiTegHzN/sg9R9x3s5wb8qHcC0YciIxiMtYNQoIk3ApeOTRXfIFIO6PQ== X-YMail-OSG: m0djFDQVM1mp0UhFU3yVVEWUJkq.Ug8rZSPiLMuCNNtJqoGv7LGtXqMBa7qYuj. U8a3Yc5gLpxD08OAQzTjsZ8RNlqo7FLpCMMw87EsxAL49cwU59d174d0R3zL4mXt42KcQOhVlk6G FwzaM16O_3RnoHD1.sQOOEQ9gzQpZIJcTV5k7uNlwQIOm.B7U.rt2mNNEMNLxN7b4ru4dZDZvdzU h15BtLVPEibZWj2IQTBCUOxOhkt9hxf1AjCBiVBl._cXcN5oltPNJc4JtS2m3F6AgjOq3r5Xf3hN eVkq_BJCEF4sCuGQAFyNDVfGtvLoQq2.NktpIkft38MzPFjdVvuPlB30Zp0i7zBDOTKz1wJCpj8I Jas7tMMz5JJVp3OZGI5J9pMTgVQITi2qX.4CTuwJzF1C37CKRvDpbruFOiwZOfdhoEMQ_qoieZZp xd9sJCnFP3aqT6eK4u0fr8emhTigWjUCrjTuTd_PaTMNMvWF2Q0vKggOoA6zoOuP.Ga9D4jtXhlL Ky_zyyZGZ8EASvOwqz8NO4qaTZ5r.lWtqMZ8SVKum0EbKcoGPxNHC..spuhpiGvVMNeQAA.2as4R kxc69v2th2KlownEtvUOoD0FCj7KjBF7f9R3RJdoY1ftA614uJ6PEQ2O.AxFIHEF9SXTAwx0Lv__ dQ1tKqce.i8.W3uMuvpWlFobrlguVH9iqKxn9cj2.36QbPk1fiT.imEiIGi5OdCLl0ZxgSEV_4vP A4zwX1fMGUZhwkFOvW1Qr1yxiHO1NKK9y_l3DZbPc4YeN98bxzP2TOodnnvmO9mRXqfbzfbFaEFQ GombdrSM1YGhHZbmdvai0rumvCWTSXAy38bMMksW8bcuG5PrClouwRuYKM8oBxX4G3eYfda4Hnzl 8yU1Idh7AfnvLXQcmcEWSQJlxIUPNBHv0tUJem7gRmFHAxffh.IB16ffXxXHA4NuVxVBsKVhwscP 7cC8AhOwHLEu6ssoPMaW8zUTFZuqihmTq8F.L275LruWUAIJ6mibbzvzqm0L8f2V2MjVmTAKgAGK EOIY.j9BffwrAo.dap_6gP5EV_ncV6Hv5yQzakp7mGyiRICxr1qKRQkz.qjVaU7AVPjQ3vG9_4G_ yZO6AFepo795C68crWjv5aSMI8QERrQYUo9GcpN39VKGLdwiDGawI945aCu_MpHK3omDoO92ftgC BOaTw8a8aijo6BTx6WYaxApNXcmrnApNuyx.vqVj.TPn0GtFL4XndCmloGb78d6mqraJdsTU3l3B WVclVlhcFCDiyLBbj9KSHu1mRBYWmqvLmNMhQ.KEDQId_SVl4pvRVIoveZbW6Suk5WLSpVZMu3XN uuHbBGBuC1TonE87.V4JBqPRjcBBnKY.B2oa6NhJSa0hsTWl43jxU99iI091gSYFqP6fU7YXfUEl LQt23jCq_oOuFKl6pCY_iG_qBJ3_7QLFMnBpRzgU4lTi7cGdOcaUvzQpE9lmbvvg8ojSw3.GDB_i uhQuGqsxtznqxotZ05ghM3YTG7wEsHS2BcL8QdQH9KSmmonHCE_jgaJn9IYXcwSFDd86fardXjIO YL4whhHobVUbllPg5RwgiX.qrjDe5KtQUrWwZj0uXm.OfeKp0hRRMPsEiIwO3glgq5yQKhK6sX81 uFFC2MKZDQprgywwhPTV3xWbrpXQyUP7FVFgZaDmMMQ791PpcCJOX47FE25voc7dGKaSIxRuk2dh btjqJA3tZnxYLPHcRurKIEB3aCXxKNJH.Z_CtTjIjQcCCL3VYCbk_zuzI2ejdFGBb8pB_dW6k7B8 GWHxVqI8n5YqoivkODnziolRaNxE0io8Zt36m8Ql0zgypSPHDgemEbEwylSbjtG55do3KcovrA3e L6u6JMlQXYs7YpT7RwwBDbDvrsgDeHQ_0ZGDFh6pMblWBQCDKUA29OkWJtrHjoI4qahEJ0i_6KuG aSwo4sAv0AyqP321pl7cagNWeAQ6C54iPu9pPvZro4EcAduDLl_kd.K54sTrLLK9fxU9n6iQshUc b77LPn1.FP95tz7.AVl0ZuuhR602MXz7WkGLvc1eu7fFZagbmTyhgQa6MUIEBmqUs3P4cTWsfYxG JZ1kBuFkZJuK2hSEk0ml0RHrmoFnfUq2AXcORKh4FH.t42IPhRZHXo_N3LLFi_88nhKIAcH0ySjr f1squCW8qKDrF60..NEN87vmZHZgXGfqtBUouda7M3R3Oc0T.qAp5RgjX07kU4kMUmLK9XTT2nEX VLgLzIOmj4cql1U5m_0Bc2bik8lybRVPNrg2pNvzdIy2OohX4JqsK1uQFGKvXXElRgdhE1b_kzEN 5auJXjOmG_uCSSgFOLQW3 X-Sonic-MF: X-Sonic-ID: b2a6b56e-591b-4d71-84c0-085a37ff2536 Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Sun, 30 Mar 2025 20:35:26 +0000 Received: by hermes--production-gq1-5c477bf655-9n48k (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 6b6bae667220c15e81d191b2abfcb110; Sun, 30 Mar 2025 20:35:22 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii 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 (Mac OS X Mail 16.0 \(3826.400.131.1.6\)) Subject: FreeBSD-15.0-CURRENT-arm64-aarch64-zfs.vhd.xz fails to boot under Hyper-V v2 on Windows 11 Pro; possibly tied to: "stand: add comconsole backwards compatibility shim for aarch64" Message-Id: <0B5B79D3-A51D-43E8-9B96-2E89B787CEC0@yahoo.com> Date: Sun, 30 Mar 2025 13:35:11 -0700 To: Warner Losh , weh@microsoft.com, FreeBSD Current , FreeBSD ARM List , Virtualisation on FreeBSD X-Mailer: Apple Mail (2.3826.400.131.1.6) References: <0B5B79D3-A51D-43E8-9B96-2E89B787CEC0.ref@yahoo.com> X-Spamd-Result: default: False [-2.63 / 15.00]; RBL_SENDERSCORE_REPUT_9(-1.00)[98.137.64.84:from]; NEURAL_HAM_LONG(-0.99)[-0.991]; NEURAL_HAM_SHORT(-0.84)[-0.841]; NEURAL_SPAM_MEDIUM(0.70)[0.702]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; TO_DN_SOME(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_FROM(0.00)[yahoo.com]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCVD_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.84:from]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.84:from]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCPT_COUNT_FIVE(0.00)[5] X-Rspamd-Queue-Id: 4ZQmH426Hmz3Tvg X-Spamd-Bar: -- In order to try to help test: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D285681 I again tried to get main FreeBSD booting on the Windows DevKit 2023 under Windows 11 Pro, this time using: FreeBSD-15.0-CURRENT-arm64-aarch64-zfs.vhd.xz (expanded to .vhd and then the .vhd converted to .vhdx since aarch64 Hyper-V only supports v2 VM's and those have to use .vhdx format, which is not directly available). It fails as described in: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D285681#c9 In part (implicit context: use of main, as is normal for my context): QUOTE I've never been able to get FreeBSD to complete much of the boot sequence under Hyper-V on the Windows DevKit 2023 (aarch64) that has Windows 11 Pro. The console output stops after the masks line of the EFI framebuffer information or somewhat later. The farthest I've seen is Event Timer line from the kernel output. It has stopped between those points otherwise. No failure notices when ti stops: just no more output. END QUOTE Also, the boot does stop, with Hyper-V indicating a not-ready status for attempts to shutdown from Hyper-V. I have to have Hyper-V just stop the VM. I tested examples from: https://download.freebsd.org/ftp/releases/VM-IMAGES/*-*/aarch64/Latest/ and all 3 of the 14.* that I tested worked: FreeBSD-14.2-STABLE-arm64-aarch64-ufs.vhd.xz FreeBSD-14.2-RELEASE-arm64-aarch64-ufs.vhd.xz FreeBSD-14.1-RELEASE-arm64-aarch64-ufs.vhd.xz Just: FreeBSD-15.0-CURRENT-arm64-aarch64-zfs.vhd.xz fails of what I tested. I'll note that comconsole for aarch64 was removed for 15+ by the following and the "shim" the commit references is only in place when: defined(__aarch64__) && __FreeBSD_version < 1500000 The commit is from 2023-May-11: From: Warner Losh Date: Thu, 11 May 2023 20:06:47 UTC The branch main has been updated by imp: URL: = https://cgit.FreeBSD.org/src/commit/?id=3Df93416d677432f3a713c71b79fb68e89= 162baca9 commit f93416d677432f3a713c71b79fb68e89162baca9 Author: Warner Losh AuthorDate: 2023-05-11 20:03:30 +0000 Commit: Warner Losh CommitDate: 2023-05-11 20:06:03 +0000 stand: add comconsole backwards compatibility shim for aarch64 Add a compat shim for the "comconsole" name so that people with a "console=3Dcomconsole" in their loader.conf on aarch64 will continue to work (though with a warning). This is only aarch64: it will never be there for amd64 (where comconsole always means talk to the hardware directly). To do that is too hard. Sponsored by: Netflix Differential Revision: https://reviews.freebsd.org/D39983 --- stand/efi/loader/conf.c | 7 +++++++ stand/efi/loader/efiserialio.c | 25 +++++++++++++++++++++++++ 2 files changed, 32 insertions(+) . . . =3D=3D=3D Mark Millard marklmi at yahoo.com