From nobody Mon Mar 31 15:39:54 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 4ZRFh24vxzz5sBcB for ; Mon, 31 Mar 2025 15:40:18 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from plan-b.pwste.edu.pl (plan-b.pwste.edu.pl [IPv6:2001:678:618::40]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "plan-b.pwste.edu.pl", Issuer "GEANT OV RSA CA 4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZRFgz752Rz3CsX for ; Mon, 31 Mar 2025 15:40:15 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=plan-b.pwste.edu.pl header.s=plan-b-mailer header.b=wlFQlLw3; dmarc=pass (policy=quarantine) header.from=plan-b.pwste.edu.pl; spf=pass (mx1.freebsd.org: domain of zarychtam@plan-b.pwste.edu.pl designates 2001:678:618::40 as permitted sender) smtp.mailfrom=zarychtam@plan-b.pwste.edu.pl Received: from [192.168.7.70] (dom.potoki.eu [62.133.140.50]) (authenticated bits=0) by plan-b.pwste.edu.pl (8.18.1/8.17.2) with ESMTPSA id 52VFdvBi041196 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Mon, 31 Mar 2025 17:40:00 +0200 (CEST) (envelope-from zarychtam@plan-b.pwste.edu.pl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=plan-b.pwste.edu.pl; s=plan-b-mailer; t=1743435602; bh=csrA3UdxM9vKpKw2+CrlX20GzdYrNgM+TH5PSFmZjGc=; h=Date:To:From:Subject; b=wlFQlLw3cffJS2vFRrQi9gBLMfDW0nXAWPXOHVWE/sXl+8n88sdK/m5eLXNRwXa08 N5VH67J0PptZIDFU8cJlP2grRBmlAXImgVrmk0BiNoJfMxYw3INLkCph5H9ZasHaDf /289YBwS5lb92Na73GrcNNTOu1pkzUe5VHGDQOluwQvj3K3tUEyW5FTa18hkNGvpwb qIC8JoHGvtCnH3HWZCgT1piz3275lls+Ld245TG4a4rkpsdYS0tlwwVH2Egb6ZICWw jdiyNBPr+7J9gg/ppoBpe10Ev2r0akafvx1+xVD0tCjbPY3wpQD+wUhxQViGMIAexp nXkfTF76nytCQ== X-Authentication-Warning: plan-b.pwste.edu.pl: Host dom.potoki.eu [62.133.140.50] claimed to be [192.168.7.70] Content-Type: multipart/alternative; boundary="------------KWuXSryfzepE6QRV3LPcBBsK" Message-ID: <234729c0-b84f-4702-a6f8-ed59c3a8e921@plan-b.pwste.edu.pl> Date: Mon, 31 Mar 2025 17:39:54 +0200 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 Content-Language: en-US To: FreeBSD Current From: Marek Zarychta Subject: Can't enable IRQ/MSI because no handler is installed Autocrypt: addr=zarychtam@plan-b.pwste.edu.pl; keydata= xsBNBFfi3cMBCADLecMTFXad4uDXqv3eRuB4qJJ8G9tzzFezeRnnwxOsPdytW5ES2z1ibSrR IsiImx6+PTqrAmXpTInxAi7yiZGdSiONRI4CCxKY9d1YFiNYT/2WyNXCekm9x29YeIU7x0JB Llbz0f/9HC+styBIu2H+PY/X98Clzm110CS+n/b9l1AtiGxTiVFj7/uavYAKxH6LNWnbkuc5 v8EVNc7NkEcl5h7Z9X5NEtzDxTOiBIFQ/kOT7LAtkYUPo1lqLeOM2DtWSXTXQgXl0zJI4iP1 OAu4qQYm2nXwq4b2AH9peknelvnt1mpfgDCGSKnhc26q6ibTfMwydp+tvUtQIQYpA6b9ABEB AAHNN01hcmVrIFphcnljaHRhIChQbGFuLWIpIDx6YXJ5Y2h0YW1AcGxhbi1iLnB3c3RlLmVk dS5wbD7CwHcEEwEIACEFAlfi4LkCGwMFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQHZW8 vIFppoJXdgf8D9X3VRFSNaR9lthSx/+uqas17J3FJKBo1xMQsC2a+44vzNvYJSuPGLLJ+LW2 HPVazjP/BWZJbxOYpliY4zxNRU0YCp0BLIVLibc//yax+mE42FND/+NiIZhqJscl6MLPrSwo sIwXec4XYkldkyqW/xBbBYXoIkBqdKB9j5j42Npy1IV/RizOSdmvTWY27ir8e/yGMR1RLr4F 8P5K3OWTdlGy2H2F/3J8bIPBLG6FpaIyLQw4dHSx8V02PYqDxK1cNo2kAOnU8PnZL/AGuMOH iv3MN1VYL8ehcmpBBsrZGebQJxrjY2/5IaTSgp9xHYT70kshuU6Qb97vk1mOjNZxgc7ATQRX 4t3DAQgA10h6RCXuBLMHxq5B8X/ZIlj9sgLoeyfRdDZEc9rT2KUeUJVHDsbvOFf4/7F1ovWY hJbA6GK/LUZeHHTjnbZcH1uDYQeHly4UOLxeEvhGoz4JhS2C7JzN/uRnwbdOAUbJr8rUj/IY a7gk906rktsc/Ldrxrxh7O6WO0JCh2XO/p4pDfEwwB37g4xHprSab28ECYJ9JMbtA8Sy4M55 g3+GQ28FvSlGnx48OoGXU2BZdc1vZKSQmNOlikB+9/hDX8zdYWVfDaX1TLQ8Ib4+xTUmapza mV/bxIsaZRBw+jFjLQHhTbIMfPEU+4mxFDvTdbKPruKPqVf1ydgMnPZWngowdwARAQABwsBf BBgBCAAJBQJX4t3DAhsMAAoJEB2VvLyBaaaC6qkIAJs9sDPqrqW0bYoRfzY6XjDWQ59p9tJi v8aogxacQNCfAu+WkJ8PNVUtC1dlVcG5NnZ80gXzd1rc8ueIvXlvdanUt/jZd8jbb3gaDbK3 wh1yMCGBl/1fOJTyEGYv1CRojv97KK89KP5+r8x1P1iHcSrunlDNqGxTMydNCwBH23QcOM+m u4spKnJ/s0VRBkw3xoKBZfZza6fTQ4gTpAipjyk7ldOGBV+PvkKATdhK2yLwuWXhKbg/GRlD 1r5P0gxzSqfV4My+KJuc2EDcrqp1y0wOpE1m9iZqCcd0fup5f7HDsYlLWshr7NQl28f6+fQb sylq/j672BHXsdeqf/Ip9V4= X-Spamd-Result: default: False [-2.84 / 15.00]; DWL_DNSWL_MED(-2.00)[pwste.edu.pl:dkim]; NEURAL_SPAM_MEDIUM(0.96)[0.958]; NEURAL_HAM_LONG(-0.96)[-0.955]; NEURAL_SPAM_SHORT(0.66)[0.661]; RCVD_DKIM_ARC_DNSWL_MED(-0.50)[]; DMARC_POLICY_ALLOW(-0.50)[plan-b.pwste.edu.pl,quarantine]; RCVD_IN_DNSWL_MED(-0.20)[2001:678:618::40:from]; R_DKIM_ALLOW(-0.20)[plan-b.pwste.edu.pl:s=plan-b-mailer]; ONCE_RECEIVED(0.20)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; ARC_NA(0.00)[]; TO_DN_ALL(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; DKIM_TRACE(0.00)[plan-b.pwste.edu.pl:+]; RCVD_COUNT_ONE(0.00)[1]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_TLS_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:206006, ipnet:2001:678:618::/48, country:PL]; HAS_XAW(0.00)[] X-Rspamd-Queue-Id: 4ZRFgz752Rz3CsX X-Spamd-Bar: -- This is a multi-part message in MIME format. --------------KWuXSryfzepE6QRV3LPcBBsK Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Dear followers of the main, I updated my desktop on Sunday, March 30th, to commit |83d13d836b32af86bba62ddf86c2ef78389d13fd|. The previous update was on March 21st, so only a small number of commits were added to the main repository in between. FWIW: Everything appears to be functioning correctly, but probably commit |0e33c2e6df7a5de65db40c7cc0fc97f66da28ccd| or |4cb527be7a251d89fa5955532300e08eec136051| introduced a change. After several hours, new messages start appearing in the kernel message buffer: "Can't enable IRQ/MSI because no handler is installed." Despite these messages, the system continues to work fine. However, once the first message appears, many more follow at intervals of 20–30 minutes. It's not annoying, but it might be worth noting. It might not be related to the commits mentioned above - my apologies if that's the case. Cheers -- Marek Zarychta --------------KWuXSryfzepE6QRV3LPcBBsK Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

Dear followers of the main,

I updated my desktop on Sunday, March 30th, to commit 83d13d836b32af86bba62ddf86c2ef78389d13fd. The previous update was on March 21st, so only a small number of commits were added to the main repository in between.

FWIW: Everything appears to be functioning correctly, but probably commit 0e33c2e6df7a5de65db40c7cc0fc97f66da28ccd or 4cb527be7a251d89fa5955532300e08eec136051 introduced a change. After several hours, new messages start appearing in the kernel message buffer: "Can't enable IRQ/MSI because no handler is installed."

Despite these messages, the system continues to work fine. However, once the first message appears, many more follow at intervals of 20–30 minutes.

It's not annoying, but it might be worth noting. It might not be related to the commits mentioned above - my apologies if that's the case.

Cheers

-- 
Marek Zarychta
--------------KWuXSryfzepE6QRV3LPcBBsK-- From nobody Mon Mar 31 16:27:52 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 4ZRGl20blbz5sFms for ; Mon, 31 Mar 2025 16:27:58 +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 4ZRGkz4dWGz3NJM; Mon, 31 Mar 2025 16:27:55 +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=KGGNFrVi; 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 52VGRqCL067657; Tue, 1 Apr 2025 01:27:52 +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=1743438472; bh=+RXaZoy/VvCQHVsjTJ+CVzyQULYtUWK8QROBReVGMKg=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=KGGNFrViqOU01axzZbK6uWLyxPDOCkgzIbcArKEVaE4KjkRXU+/oFnO277j/bVWVc F+xRaP+5HGywBr7gJXdgC5Pq1yy6L6Ud+siXdnbGE3wS24DuhDcqdVDWeWIT6Oq7Fs IEbCrPWnpxhkXoPV90kz45sU8C62K243XcA0KFcI= Date: Tue, 1 Apr 2025 01:27:52 +0900 From: Tomoaki AOKI To: Ed Maste Cc: FreeBSD Current Subject: Re: Heads-up: Kernel module symbol resolution changing Message-Id: <20250401012752.22e5a1312c1f363544b40a57@dec.sakura.ne.jp> In-Reply-To: References: <20250315120317.e6b2512e8d37e7f51d1aab03@dec.sakura.ne.jp> 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 [2.60 / 15.00]; SUSPICIOUS_URL_IN_SUSPICIOUS_MESSAGE(1.00)[]; NEURAL_SPAM_LONG(0.84)[0.844]; URIBL_RED(0.50)[dec.sakura.ne.jp:dkim,dec.sakura.ne.jp:mid,dec.sakura.ne.jp:email]; MV_CASE(0.50)[]; NEURAL_HAM_SHORT(-0.41)[-0.411]; ONCE_RECEIVED(0.20)[]; NEURAL_HAM_MEDIUM(-0.13)[-0.130]; HAS_ANON_DOMAIN(0.10)[]; BAD_REP_POLICIES(0.10)[]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; R_DKIM_ALLOW(0.00)[dec.sakura.ne.jp:s=s2405]; DMARC_POLICY_ALLOW(0.00)[dec.sakura.ne.jp,none]; R_SPF_ALLOW(0.00)[+ip4:153.125.133.16/28]; HAS_ORG_HEADER(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[dec.sakura.ne.jp:+]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+] X-Rspamd-Queue-Id: 4ZRGkz4dWGz3NJM X-Spamd-Bar: ++ On Mon, 31 Mar 2025 10:57:45 -0400 Ed Maste wrote: > On Fri, 14 Mar 2025 at 23:03, Tomoaki AOKI wrote: > > > > On Wed, 12 Mar 2025 13:07:58 -0400 > > Ed Maste wrote: > > > > > Our in-kernel module linker currently performs symbol resolution > > > against local symbols from other modules, which is a bug. > > > > > Hi. > > Is this planned only for main (aka 15-Current)? Or any plan to MFC? > > Right now I plan to do it only in main. The current behaviour is > undesired, but I strongly prefer to avoid changes like this in stable > branches that could surprise users. Thanks for the clarification. And yes, POLA violations on stable and releng branches should be avoided, unless it is mandated to address workaround-less security vulnerabilities. Regards. -- Tomoaki AOKI From nobody Tue Apr 1 10:17:36 2025 X-Original-To: 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 4ZRkTj6WS6z5sHXG for ; Tue, 01 Apr 2025 10:18:01 +0000 (UTC) (envelope-from dch@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 4ZRkTj5fN3z3Hsh for ; Tue, 01 Apr 2025 10:18:01 +0000 (UTC) (envelope-from dch@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1743502681; 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; bh=8hawD4bssdGU2myKy5oPGmJGZrUIoKiJCTtqGbqtpN4=; b=W6Xgc33jNQHq2RKgx/AwDnfirTwTcGQma2GG56PyqppE/7GkCMaRcEQlJCBsPuiRpCzGUx QjGFbZfZrmiWLOr8IQvKKIbI1TJA4XwUS+9023bNRIsnUWuL0O9eOD27OAWq7zmVOhyCJ8 8FONtavHy6inM45ZWYQiT29WuK188EL2RL+5OfyorZvaIzW3SaGgi7/h4rvkCvJes3ajyT 0WVnfetGYKUtRnnW2WZZkalBvKDnV57JPZsE1x0AkWo4ZrSLnPD1GDd11ZoZQXyl44OL+p YJtDwt5nX7kWeqN8QAJBfyIQQKWPanciCOZUMvTjfep6eLtyZfMm7kZ0kWBMug== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1743502681; a=rsa-sha256; cv=none; b=n+uNVZyIWxtBZmxUcI35gaoPTDxUd4YiM2Lb7R2j1UiiS0HbSYbWFemfkj8IaVZB+bgTbc qio6kV420CCNvXI4mEhNF5B5/e6KRKvHFE0/CW8m/DJitfg6S+AxKv+mbfSYpq3lF36GM4 ce+KZM0v3oS1EBGicyflF1/UOv3tevyYjl7JvINOu3fKP5pLj4qjxR3s905AsuoDskZwrb UaHgYcPF/DuCwCTNEs6MLJo8M5aIXZNhtphs7Zms0l81/y4APLKiVNqyZMoXXBEt0YkVoV nUwtByC2Dzl1EcRbc6OddNvsWyRGOryITDjZmWAFtXKVxEWTT4lMyuspcE+A6Q== 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=1743502681; 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; bh=8hawD4bssdGU2myKy5oPGmJGZrUIoKiJCTtqGbqtpN4=; b=qWURm8GJAJqfzh1PRV+zeCKwYz2BAfiH4vv+RoojtM/k2S8lEOHF5NpOXQ/I9tgmCxADyp ZmYD5Sp70zO7CM5cOaI2aUtcND3M/XB39hVX7mflcemupa8PbXDiYEMuWRcK43bzXxnpCs CSGkXs/cfPNJ803SiHmJ/0LDM8FviQuYyPYxrPPAubmo4RWUvfiyRHw5eTvDE9heaYHhmH flZ7acwLo+hMnf3QJlN/UdHfi7/z4gCLhlJpDS232jWKbSdy4hZz2/NsTDQegTnD9a387Y 6G4qr0C/ibxqb9vPT33HWdWc3uCCrQRzkZ8815zCojIsT7GBYfBH7moI6KkqyA== Received: from fauth-a2-smtp.messagingengine.com (fauth-a2-smtp.messagingengine.com [103.168.172.201]) (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: dch/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4ZRkTj4W37z8Fc for ; Tue, 01 Apr 2025 10:18:01 +0000 (UTC) (envelope-from dch@FreeBSD.org) Received: from phl-compute-08.internal (phl-compute-08.phl.internal [10.202.2.48]) by mailfauth.phl.internal (Postfix) with ESMTP id 10EF5120007A for ; Tue, 1 Apr 2025 06:17:57 -0400 (EDT) Received: from phl-imap-15 ([10.202.2.104]) by phl-compute-08.internal (MEProxy); Tue, 01 Apr 2025 06:17:57 -0400 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgddukedvhedvucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggv pdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucenucfjughrpefogg ffhffvkffutgfgsehtqhertdertdejnecuhfhrohhmpedfffgrvhgvucevohhtthhlvghh uhgsvghrfdcuoegutghhsefhrhgvvgeuufffrdhorhhgqeenucggtffrrghtthgvrhhnpe eggfeifeejvddvueeikeejtefguefftedvhfefueetheffvddtkeduheevieeludenucff ohhmrghinhepohhpvghnshhushgvrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenuc frrghrrghmpehmrghilhhfrhhomhepuggthhdomhgvshhmthhprghuthhhphgvrhhsohhn rghlihhthidquddvgeeluddtfeeguddquddvudefuddujeejqdgutghhpeephfhrvggvue fuffdrohhrghesfhgrshhtmhgrihhlrdhfmhdpnhgspghrtghpthhtohepuddpmhhouggv pehsmhhtphhouhhtpdhrtghpthhtoheptghurhhrvghnthesfhhrvggvsghsugdrohhrgh X-ME-Proxy: Feedback-ID: icedc46df:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id D453E78006A; Tue, 1 Apr 2025 06:17:56 -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 Date: Tue, 01 Apr 2025 10:17:36 +0000 From: "Dave Cottlehuber" To: current@freebsd.org Message-Id: <7d155dfe-800c-4ba4-b59b-bf710ab45991@app.fastmail.com> Subject: nfs4: some shares have invisible files & directories Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable TLDR I have working nfs4 mounts but in some mounts, none of the files are visible to ls etc. But if you know the filename, you can still access it directly by name. Why? I should have a very simple setup for nfsv4. What I need is to have ro exports /usr/{ports,obj,src} available to clients, all=20 FreeBSD. I can mount all exported filesystems, but only /usr/obj has visible files on the client, and I don't understand why. This behaviour is consistent across clients. during beinstall.sh from clients, they are unable to access files that definitely exist in /usr/obj/* such as /usr/bin/cc & /bin/rm.=20 It was "resolved" by `zfs destroy zroot/usr/{ports,src}` & recreating them. I don't recall ever using getfacl/setfacl, and I can't think of anything else that might make the mount work but the files be invisible. Sadly I did not think to just rename the afflicted datasets. Does anybody know what might cause this? I did find a mention of this from SUSE linux, but in 2011, and I don't see any interesting commits related to readdir recently. https://forums.opensuse.org/t/11-4-strange-nfs-v4-problem-invisible-file= s/63107 ## server - fast build box running nfsv4 only - 15-CURRENT, up to date - providing /usr/{src,obj,ports} to 3 clients - this is a zfs system, and each are on separate datasets ``` # egrep -hr 'nfs|mount' /etc/rc.conf* mountd_enable=3DYES nfs_server_enable=3DYES nfsv4_server_enable=3DYES nfsv4_server_only=3DYES # cat /etc/exports V4: /usr -sec=3Dsys /usr/src -ro /usr/obj -ro /usr/ports -ro # ls -AFGhld /usr/{src,obj,ports} drwxr-xr-x 3 dch wheel 3B Feb 28 23:27 /usr/obj/ drwxr-xr-x 70 dch wheel 86B Apr 1 06:55 /usr/ports/ drwxr-xr-x 27 dch wheel 47B Mar 31 13:26 /usr/src/ # getfacl /usr/src # file: /usr/src # owner: dch # group: wheel owner@:rwxp--aARWcCos:-------:allow group@:rwxp--a-R-c--s:-------:allow everyone@:r-x---a-R-c--s:-------:allow # getfacl /usr/src/COPYRIGHT # file: /usr/src/COPYRIGHT # owner: dch # group: wheel owner@:rw-p--aARWcCos:-------:allow group@:rw-p--a-R-c--s:-------:allow everyone@:r-----a-R-c--s:-------:allow ``` # clients - either 14.2-RELEASE or also 15-CURRENT - no daemons ``` # mount_nfs -o vers=3D4,nolockd,retrycnt=3D0,noatime,ro 172.16.1.4:/obj = /usr/obj # ls /usr/obj/usr/src/amd64.amd64/ bin/ ... lots more files, very good # mount_nfs -o vers=3D4,nolockd,retrycnt=3D0,noatime,ro 172.16.1.4:/src = /usr/src # mkdir /usr/src/foo mkdir: /usr/src/foo: Read-only file system # good its clearly mounted # ls -AFGhl /usr/src total 0 # head /usr/src/COPYRIGHT The compilation of software known as FreeBSD is distributed under the following terms: .... what how is this file even here? ls shows nothing, tar also fails ``` A+ Dave =E2=80=94=E2=80=94=E2=80=94 O for a muse of fire, that would ascend the brightest heaven of inventio= n! From nobody Tue Apr 1 10:39:54 2025 X-Original-To: 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 4ZRkz74Jflz5sK1P for ; Tue, 01 Apr 2025 10:40:03 +0000 (UTC) (envelope-from SRS0=hXZs=WT=klop.ws=ronald-lists@realworks.nl) Received: from smtp-relay-int-backup.realworks.nl (smtp-relay-int-backup.realworks.nl [87.255.56.188]) (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 4ZRkz71mdgz3ThT; Tue, 01 Apr 2025 10:40:03 +0000 (UTC) (envelope-from SRS0=hXZs=WT=klop.ws=ronald-lists@realworks.nl) Authentication-Results: mx1.freebsd.org; none Received: from smtp-relay-int.realworks.nl (rwvirtual375.colo.realworks.nl [10.0.10.75]) by mailrelayint1.colo2.realworks.nl (Postfix) with ESMTP id 4ZRkyy6qMDz1lq; Tue, 1 Apr 2025 12:39:54 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2; t=1743503995; 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=lITHTZ0vZ6HzLd7ON9acwZrPCb+K5Jx8++gmYNdbdVQ=; b=rU6r6Dd1OAlOSUkh+rdYTHFo2Fus8+3i6irk+oM9H4J+cCCUNRrnubVqBsnshMrDSpVrSp dKNk5Qchs61bibG1Rodf0u6+CRWYeXNu3HHrLsVS5vDzyEL+DY1BtXrTlALII+dWtsUnRs AiQCP5qRrXqr//e0AgCoJ5p3CVSt0VUXVKjtIh9G4WZ941/itlQU7gyn9qRSD3enboqNNi 0va5YvL2LBgxyDyVcAKTeQ/MvpYclnG20CNF8bITfeZcGFvlPKByyXh2/3pV0RAFh+O24m IwKdQWvkhaYS3nVJuP3Mm/Q/gRzRQq3yrZy4czIWfKy8S+e3R9vqlsd4tyKcfA== Received: from rwvirtual375.colo.realworks.nl (localhost [127.0.0.1]) by rwvirtual375.colo.realworks.nl (Postfix) with ESMTP id DA57740030; Tue, 1 Apr 2025 12:39:54 +0200 (CEST) Date: Tue, 1 Apr 2025 12:39:54 +0200 (CEST) From: Ronald Klop To: Dave Cottlehuber Cc: current@freebsd.org Message-ID: <2001775390.7235.1743503994892@localhost> In-Reply-To: <7d155dfe-800c-4ba4-b59b-bf710ab45991@app.fastmail.com> References: <7d155dfe-800c-4ba4-b59b-bf710ab45991@app.fastmail.com> Subject: Re: nfs4: some shares have invisible files & directories 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="----=_Part_7234_805019400.1743503994890" X-Mailer: Realworks (744.30) X-Originating-Host: from (84-105-120-103.cable.dynamic.v4.ziggo.nl [84.105.120.103]) by rwvirtual375 [10.0.10.75] with HTTP; Tue, 01 Apr 2025 12:39:54 +0200 Importance: Normal X-Priority: 3 (Normal) X-Originating-User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:136.0) Gecko/20100101 Firefox/136.0 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:38930, ipnet:87.255.32.0/19, country:NL] X-Rspamd-Queue-Id: 4ZRkz71mdgz3ThT X-Spamd-Bar: ---- ------=_Part_7234_805019400.1743503994890 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi, Do you have some local filesytem mounted over the NFS4 mount? Your remark a= bout 'It was "resolved" by `zfs destroy zroot/usr/{ports,src}`' made me thi= nk in this direction. Did you do the zfs destroy on the NFS client or on th= e NFS server? Regards, Ronald. =20 Van: Dave Cottlehuber Datum: dinsdag, 1 april 2025 12:17 Aan: current@freebsd.org Onderwerp: nfs4: some shares have invisible files & directories >=20 > TLDR I have working nfs4 mounts but in some mounts, none of the > files are visible to ls etc. But if you know the filename, you can > still access it directly by name. Why? >=20 > I should have a very simple setup for nfsv4. What I need is to > have ro exports /usr/{ports,obj,src} available to clients, all > FreeBSD. >=20 > I can mount all exported filesystems, but only /usr/obj has visible > files on the client, and I don't understand why. This behaviour is > consistent across clients. >=20 > during beinstall.sh from clients, they are unable to access files > that definitely exist in /usr/obj/* such as /usr/bin/cc & /bin/rm. >=20 > It was "resolved" by `zfs destroy zroot/usr/{ports,src}` & recreating > them. I don't recall ever using getfacl/setfacl, and I can't think > of anything else that might make the mount work but the files > be invisible. Sadly I did not think to just rename the afflicted > datasets. >=20 > Does anybody know what might cause this? I did find a mention of > this from SUSE linux, but in 2011, and I don't see any interesting > commits related to readdir recently. >=20 > https://forums.opensuse.org/t/11-4-strange-nfs-v4-problem-invisible-files= /63107 >=20 > ## server >=20 > - fast build box running nfsv4 only > - 15-CURRENT, up to date > - providing /usr/{src,obj,ports} to 3 clients > - this is a zfs system, and each are on separate datasets >=20 > ``` > # egrep -hr 'nfs|mount' /etc/rc.conf* >=20 > mountd_enable=3DYES > nfs_server_enable=3DYES > nfsv4_server_enable=3DYES > nfsv4_server_only=3DYES >=20 > # cat /etc/exports > V4: /usr -sec=3Dsys > /usr/src -ro > /usr/obj -ro > /usr/ports -ro >=20 > # ls -AFGhld /usr/{src,obj,ports} > drwxr-xr-x 3 dch wheel 3B Feb 28 23:27 /usr/obj/ > drwxr-xr-x 70 dch wheel 86B Apr 1 06:55 /usr/ports/ > drwxr-xr-x 27 dch wheel 47B Mar 31 13:26 /usr/src/ >=20 > # getfacl /usr/src > # file: /usr/src > # owner: dch > # group: wheel > owner@:rwxp--aARWcCos:-------:allow > group@:rwxp--a-R-c--s:-------:allow > everyone@:r-x---a-R-c--s:-------:allow > # getfacl /usr/src/COPYRIGHT > # file: /usr/src/COPYRIGHT > # owner: dch > # group: wheel > owner@:rw-p--aARWcCos:-------:allow > group@:rw-p--a-R-c--s:-------:allow > everyone@:r-----a-R-c--s:-------:allow > ``` >=20 > # clients >=20 > - either 14.2-RELEASE or also 15-CURRENT > - no daemons >=20 > ``` > # mount_nfs -o vers=3D4,nolockd,retrycnt=3D0,noatime,ro 172.16.1.4:/obj /= usr/obj > # ls /usr/obj/usr/src/amd64.amd64/ > bin/ ... lots more files, very good >=20 > # mount_nfs -o vers=3D4,nolockd,retrycnt=3D0,noatime,ro 172.16.1.4:/src /= usr/src > # mkdir /usr/src/foo > mkdir: /usr/src/foo: Read-only file system # good its clearly mounted >=20 > # ls -AFGhl /usr/src > total 0 >=20 > # head /usr/src/COPYRIGHT > The compilation of software known as FreeBSD is distributed under the > following terms: > .... what how is this file even here? ls shows nothing, tar also fails > ``` >=20 > A+ > Dave > =E2=80=94=E2=80=94=E2=80=94 > O for a muse of fire, that would ascend the brightest heaven of invention= ! > =20 >=20 >=20 >=20 =20 ------=_Part_7234_805019400.1743503994890 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi,

Do you have some local filesytem mounted over the NFS4 mount? Your remark a= bout 'It was "resolved" by `zfs destroy zroot/usr/{ports,src}`' made me thi= nk in this direction. Did you do the zfs destroy on the NFS client or on th= e NFS server?

Regards,
Ronald.

 

Van: Dave Cottlehuber <dch@FreeBSD.org>
Datum: dinsdag, 1 april 2025 12:17
Aan: current@freebsd.org
Onderwerp: nfs4: some shares have invisible files & di= rectories

TLDR I have working nfs4 mounts b= ut in some mounts, none of the
files are visible to ls etc. But if you know the filename, you can
still access it directly by name. Why?

I should have a very simple setup for nfsv4. What I need is to
have ro exports /usr/{ports,obj,src} available to clients, all
FreeBSD.

I can mount all exported filesystems, but only /usr/obj has visible
files on the client, and I don't understand why. This behaviour is
consistent across clients.

during beinstall.sh from clients, they are unable to access files
that definitely exist in /usr/obj/* such as /usr/bin/cc & /bin/rm.

It was "resolved" by `zfs destroy zroot/usr/{ports,src}` & recreating them. I don't recall ever using getfacl/setfacl, and I can't think
of anything else that might make the mount work but the files
be invisible. Sadly I did not think to just rename the afflicted
datasets.

Does anybody know what might cause this? I did find a mention of
this from SUSE linux, but in 2011, and I don't see any interesting
commits related to readdir recently.

https://forums.opensuse.org/t/11-4-strange-nfs-v4-problem-= invisible-files/63107

## server

- fast build box running nfsv4 only
- 15-CURRENT, up to date
- providing /usr/{src,obj,ports} to 3 clients
- this is a zfs system, and each are on separate datasets

```
# egrep -hr 'nfs|mount' /etc/rc.conf*

mountd_enable=3DYES
nfs_server_enable=3DYES
nfsv4_server_enable=3DYES
nfsv4_server_only=3DYES

# cat /etc/exports
V4: /usr -sec=3Dsys
/usr/src -ro
/usr/obj -ro
/usr/ports -ro

# ls -AFGhld /usr/{src,obj,ports}
drwxr-xr-x   3 dch wheel    3B Feb 28 23:27 /usr/o= bj/
drwxr-xr-x  70 dch wheel   86B Apr  1 06:55 /usr/ports/=
drwxr-xr-x  27 dch wheel   47B Mar 31 13:26 /usr/src/

# getfacl /usr/src
# file: /usr/src
# owner: dch
# group: wheel
            own= er@:rwxp--aARWcCos:-------:allow
            gro= up@:rwxp--a-R-c--s:-------:allow
         everyone@:r-x---a-R-c= --s:-------:allow
# getfacl /usr/src/COPYRIGHT
# file: /usr/src/COPYRIGHT
# owner: dch
# group: wheel
            own= er@:rw-p--aARWcCos:-------:allow
            gro= up@:rw-p--a-R-c--s:-------:allow
         everyone@:r-----a-R-c= --s:-------:allow
```

# clients

- either 14.2-RELEASE or also 15-CURRENT
- no daemons

```
# mount_nfs -o vers=3D4,nolockd,retrycnt=3D0,noatime,ro 172.16.1.4:/obj /us= r/obj
# ls /usr/obj/usr/src/amd64.amd64/
bin/  ... lots more files, very good

# mount_nfs -o vers=3D4,nolockd,retrycnt=3D0,noatime,ro 172.16.1.4:/src /us= r/src
# mkdir /usr/src/foo
mkdir: /usr/src/foo: Read-only file system # good its clearly mounted

# ls -AFGhl /usr/src
total 0

# head /usr/src/COPYRIGHT
The compilation of software known as FreeBSD is distributed under the
following terms:
.... what how is this file even here? ls shows nothing, tar also fails
```

A+
Dave
=E2=80=94=E2=80=94=E2=80=94
O for a muse of fire, that would ascend the brightest heaven of invention!<= br>  

  ------=_Part_7234_805019400.1743503994890-- From nobody Tue Apr 1 13:21:16 2025 X-Original-To: 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 4ZRpYZ1gvYz5rWl1 for ; Tue, 01 Apr 2025 13:21:38 +0000 (UTC) (envelope-from dch@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 4ZRpYZ10dKz3NwG; Tue, 01 Apr 2025 13:21:38 +0000 (UTC) (envelope-from dch@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1743513698; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=DBn+RvFmeDMNiMVHn5O3OKPDET2S0TA0bDtwXL2Pjys=; b=V8bc721J4ow597XybXdttyqK8OZz+ekN2+XyAQREL3WMxVTHQHJAPy8mBrtbb9sbpxuHG+ v007QyMZpagduHMPbueWpKeVKxZw4WiPlMcFZsH5Nr6UC3szqiSu6YxRbCa0G1xwJkN0UG 0f86V306ieW6eAtLP9ilSUSjUNl58yL8UDuvsVdbO/88PuQ9iz09Ro8be7a5IzSRlKCwQB L3Bn3DyI5JlyZ1l1eVXA1OhwPqu4fVKvOoCMXVSrZ4kau53T8WEfFVzkQ9s0O+BMIxL+4x FvvQbktmTyYjmogjKke1BOTxRToOOAlv16ugvNdbtt7XTInWVw8cSL65E5FmsA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1743513698; a=rsa-sha256; cv=none; b=i8/snEyVA0obilQ655CfcuPdzLHH6FqyP1bBm6td+fzwWiW+qPi89JkNtdsTb9Ac7OXCvF 8uaIFabcKrF+Qpd1Kau9qY0nzn9G2cFEGer+w1kQgk7EpPqLvUYwAPLGcgrW/+mPxvoAuK U0+7sv5ZKwXo1a0bpd3iBD2Jfec4ZA3o6mJui2GgIbWDqqa7zfytHXT5LLZ7ZZWX/WYykY 8Kr56Dv77hcioTlqUzpagBcfhAmlQVrHfkNDkK9WAqgeIE+SmPNfCYCdFOX/mDysv5ludl y2xM9j6Ged+/lCPE1st9U5oY1sjlK6RFILF13vlmaL5sspgp4P0WuLV4HaQ3SA== 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=1743513698; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=DBn+RvFmeDMNiMVHn5O3OKPDET2S0TA0bDtwXL2Pjys=; b=VZfRaM+D7AcbaMNglpbMTMM8Q51sgehyNGVlKoqbKkFG/BDMm77JrftnSHCeP7njcZwzbP JZKXdKIcJTgPpSYAsqHO7JQJRV6/l3FB5Huu1xyP1dh+u9hChTRYTwdMIyFvZFn3uiFtkz pudGjRkrAjEZzo5vsHjq9ugJcpDOlYHT+wnUFpz8bEYTw54cCrbyD/5y2C32k2pSpF0ldb +Zh8DSSlhfRWJGDlzM+JZIe3C9n/QGRPJynNiaW5QWF7sz0jPsgrkkS22V1Ujv9wUTw9XQ W16rvBWElLUgoNbCDMGy72X4tqvBJTElkiJSxPSj+8DSIYGtsJu6XgnXLrcsmw== Received: from fauth-a1-smtp.messagingengine.com (fauth-a1-smtp.messagingengine.com [103.168.172.200]) (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: dch/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4ZRpYZ05x0zCPw; Tue, 01 Apr 2025 13:21:37 +0000 (UTC) (envelope-from dch@FreeBSD.org) Received: from phl-compute-08.internal (phl-compute-08.phl.internal [10.202.2.48]) by mailfauth.phl.internal (Postfix) with ESMTP id C05C71200069; Tue, 1 Apr 2025 09:21:37 -0400 (EDT) Received: from phl-imap-15 ([10.202.2.104]) by phl-compute-08.internal (MEProxy); Tue, 01 Apr 2025 09:21:37 -0400 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgddukedvkeelucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggv pdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucenucfjughrpefogg ffhffvvefkjghfufgtgfesthejredtredttdenucfhrhhomhepfdffrghvvgcuvehothht lhgvhhhusggvrhdfuceouggthheshfhrvggvuefuffdrohhrgheqnecuggftrfgrthhtvg hrnhepffdukeelkeekueeludelteetvdegffejudelgedugfdtleehteelgeevtdefvdeh necuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepuggthh domhgvshhmthhprghuthhhphgvrhhsohhnrghlihhthidquddvgeeluddtfeeguddquddv udefuddujeejqdgutghhpeephfhrvggvuefuffdrohhrghesfhgrshhtmhgrihhlrdhfmh dpnhgspghrtghpthhtohepvddpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtoheptghu rhhrvghnthesfhhrvggvsghsugdrohhrghdprhgtphhtthhopehrohhnrghlugdqlhhish htsheskhhlohhprdifsh X-ME-Proxy: Feedback-ID: icedc46df:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id 9057278006A; Tue, 1 Apr 2025 09:21:37 -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: T906582bb83fef1b5 Date: Tue, 01 Apr 2025 13:21:16 +0000 From: "Dave Cottlehuber" To: "Ronald Klop" Cc: current@freebsd.org Message-Id: In-Reply-To: <2001775390.7235.1743503994892@localhost> References: <7d155dfe-800c-4ba4-b59b-bf710ab45991@app.fastmail.com> <2001775390.7235.1743503994892@localhost> Subject: Re: nfs4: some shares have invisible files & directories Content-Type: text/plain Content-Transfer-Encoding: 7bit On Tue, 1 Apr 2025, at 10:39, Ronald Klop wrote: > Hi, > > Do you have some local filesytem mounted over the NFS4 mount? Your thanks, oo, but I did check this & it wasn't the culprit. The same issue (invisible dirs/folders) was present from 3 different clients. > remark about 'It was "resolved" by `zfs destroy zroot/usr/{ports,src}`' > made me think in this direction. Did you do the zfs destroy on the NFS > client or on the NFS server? On the server only. A+ Dave From nobody Tue Apr 1 18:21: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 4ZRxD15csYz5rvJD for ; Tue, 01 Apr 2025 18:21:53 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZRxCz3fwzz3jpF for ; Tue, 01 Apr 2025 18:21:51 +0000 (UTC) (envelope-from guru@unixarea.de) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=unixarea.de header.s=blu3434000 header.b=KKmXMRwy; dmarc=none; spf=pass (mx1.freebsd.org: domain of guru@unixarea.de designates 178.254.4.101 as permitted sender) smtp.mailfrom=guru@unixarea.de DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=unixarea.de ; s=blu3434000; h=Content-Transfer-Encoding:Content-Type:MIME-Version: Reply-To:Message-ID:Subject:To:From:Date:Sender:Cc:Content-ID: Content-Description:In-Reply-To:References; bh=7X3rAc7EaxloNWYXHtulfVz1XoV9beRcAk3bAC7Rbtk=; b=KKmXMRwyMgO4OQy2B0iZSt4iZG MzJNCpCx9GvSOLrR+iMcHLMqSX+3pQqbBIUDADe+f129jW44DVIP9In9wE6EFhJ2w9h8mh5XTlStI MyT+0zfqP+9B63JAgm0z2U3gSwyGRZUD8gLH8Yty5Hlpcmq6mEhjPMqESsT1vk5EsuU6LznlNDvGs rEqlcKUP8StCJYxOpUiTH53flu+TFdmImWrgpB/j4QSmNHzhoP6XDU5AqcTISO7/8s7nSTlzx4d5s Bwcxv04xS4owNTnqpajfrLNELNlN4X9KVqFkWmBeM6mcRQhlbtGp9aFp96i86e7zMAG/0XnAmrOIk D8hRtDCQ==; Received: from [80.187.83.57] (helo=localhost.unixarea.de) by ms-10.1blu.de with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1tzgFA-00H22d-HN; Tue, 01 Apr 2025 20:21:48 +0200 Received: from localhost.my.domain (c720-1400094 [127.0.0.1]) by localhost.unixarea.de (8.17.1/8.14.9) with ESMTP id 531ILluF008434; Tue, 1 Apr 2025 20:21:47 +0200 (CEST) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.17.1/8.14.9/Submit) id 531ILlmw008433; Tue, 1 Apr 2025 20:21:47 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Tue, 1 Apr 2025 20:21:47 +0200 From: Matthias Apitz To: freebsd-current@freebsd.org Subject: USB keyboard Polygon 7 not recogniced Message-ID: Reply-To: Matthias Apitz Mail-Followup-To: freebsd-current@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="P8nCfaYFQseVLSUx" Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Operating-System: FreeBSD 14.0-CURRENT r1400094 (amd64) X-message-flag: Mails in HTML will not be read! Please, only plain text. X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 80.187.83.57 X-Spamd-Result: default: False [-3.45 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.996]; NEURAL_HAM_MEDIUM(-0.95)[-0.949]; MID_RHS_NOT_FQDN(0.50)[]; RWL_MAILSPIKE_EXCELLENT(-0.40)[178.254.4.101:from]; R_DKIM_ALLOW(-0.20)[unixarea.de:s=blu3434000]; R_SPF_ALLOW(-0.20)[+ip4:178.254.4.101]; MIME_GOOD(-0.10)[multipart/mixed,text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[178.254.4.101:from]; TO_DN_NONE(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DMARC_NA(0.00)[unixarea.de]; SUSPICIOUS_AUTH_ORIGIN(0.00)[]; ARC_NA(0.00)[]; HAS_XAW(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+]; RCPT_COUNT_ONE(0.00)[1]; TO_MATCH_ENVRCPT_ALL(0.00)[]; HAS_ATTACHMENT(0.00)[]; DKIM_TRACE(0.00)[unixarea.de:+]; FROM_HAS_DN(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; HAS_XOIP(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MISSING_XM_UA(0.00)[]; ASN(0.00)[asn:42730, ipnet:178.254.0.0/19, country:DE]; HAS_REPLYTO(0.00)[guru@unixarea.de]; REPLYTO_EQ_FROM(0.00)[] X-Rspamd-Queue-Id: 4ZRxCz3fwzz3jpF X-Spamd-Bar: --- --P8nCfaYFQseVLSUx Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit Hello, My son (15 years old, Linux freak) bought for his PC such an USB keyboard kit: https://d-r.works/products/polygon-7-keyboard-kit (One can build the keyboard layout on own ideas.) It works fine on his PC connected via USB. On my beloved FreeBSD 14-CURRENT it gives in /var/log/messages on attach: Apr 1 19:22:21 c720-1400094 kernel: ugen0.4: at usbus0 Apr 1 19:22:21 c720-1400094 kernel: ukbd0 on uhub0 Apr 1 19:22:21 c720-1400094 kernel: ukbd0: on usbus0 Apr 1 19:22:21 c720-1400094 kernel: kbd2 at ukbd0 Apr 1 19:22:21 c720-1400094 kernel: uhid0 on uhub0 Apr 1 19:22:21 c720-1400094 kernel: uhid0: on usbus0 Apr 1 19:22:21 c720-1400094 kernel: ums0 on uhub0 Apr 1 19:22:21 c720-1400094 kernel: ums0: on usbus0 Apr 1 19:22:21 c720-1400094 kernel: ums0: 8 buttons and [XYZT] coordinates ID=2 But no keypress is visible in any terminal. I will attach as well, what my Debian Linux cellular says on attache and there it works fine too. The idVendor=1d6b and idProduct=0002 visible in /var/log/syslog in Debian are not shown in FreeBSD. Perhaps we miss them in our driver? matthias -- Matthias Apitz, ✉ guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub --P8nCfaYFQseVLSUx Content-Type: text/plain; charset=utf-8 Content-Disposition: attachment; filename="pg7-L5.txt" Apr 1 19:29:09 pureos kernel: [57355.003675] xhci-hcd xhci-hcd.5.auto: xHCI Host Controller Apr 1 19:29:09 pureos kernel: [57355.003710] xhci-hcd xhci-hcd.5.auto: new USB bus registered, assigned bus number 3 Apr 1 19:29:09 pureos kernel: [57355.003825] xhci-hcd xhci-hcd.5.auto: hcc params 0x0220fe6c hci version 0x110 quirks 0x0000008000000010 Apr 1 19:29:09 pureos kernel: [57355.003868] xhci-hcd xhci-hcd.5.auto: irq 207, io mem 0x38100000 Apr 1 19:29:09 pureos kernel: [57355.004049] xhci-hcd xhci-hcd.5.auto: xHCI Host Controller Apr 1 19:29:09 pureos kernel: [57355.004062] xhci-hcd xhci-hcd.5.auto: new USB bus registered, assigned bus number 4 Apr 1 19:29:09 pureos kernel: [57355.004074] xhci-hcd xhci-hcd.5.auto: Host supports USB 3.0 SuperSpeed Apr 1 19:29:09 pureos kernel: [57355.004555] bq25890-charger 3-006a: Upstream supply changed: 0. Apr 1 19:29:09 pureos kernel: [57355.004567] bq25890-charger 3-006a: Enabling OTG_EN pin Apr 1 19:29:09 pureos kernel: [57355.004736] usb usb3: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 6.06 Apr 1 19:29:09 pureos kernel: [57355.004745] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1 Apr 1 19:29:09 pureos kernel: [57355.004751] usb usb3: Product: xHCI Host Controller Apr 1 19:29:09 pureos kernel: [57355.004756] usb usb3: Manufacturer: Linux 6.6.0-1-librem5 xhci-hcd Apr 1 19:29:09 pureos kernel: [57355.004761] usb usb3: SerialNumber: xhci-hcd.5.auto Apr 1 19:29:09 pureos kernel: [57355.007151] hub 3-0:1.0: USB hub found Apr 1 19:29:09 pureos kernel: [57355.007207] hub 3-0:1.0: 1 port detected Apr 1 19:29:09 pureos kernel: [57355.007751] usb usb4: We don't know the algorithms for LPM for this host, disabling LPM. Apr 1 19:29:09 pureos kernel: [57355.007872] usb usb4: New USB device found, idVendor=1d6b, idProduct=0003, bcdDevice= 6.06 Apr 1 19:29:09 pureos kernel: [57355.007884] usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1 Apr 1 19:29:09 pureos kernel: [57355.007893] usb usb4: Product: xHCI Host Controller Apr 1 19:29:09 pureos kernel: [57355.007901] usb usb4: Manufacturer: Linux 6.6.0-1-librem5 xhci-hcd Apr 1 19:29:09 pureos kernel: [57355.007908] usb usb4: SerialNumber: xhci-hcd.5.auto Apr 1 19:29:09 pureos kernel: [57355.010921] hub 4-0:1.0: USB hub found Apr 1 19:29:09 pureos kernel: [57355.010966] hub 4-0:1.0: 1 port detected Apr 1 19:29:09 pureos kernel: [57355.011506] bq25890-charger 3-006a: Upstream supply changed: 0. Apr 1 19:29:09 pureos kernel: [57355.011521] bq25890-charger 3-006a: Enabling OTG_EN pin Apr 1 19:29:09 pureos kernel: [57355.027887] bq25890-charger 3-006a: Upstream supply changed: 0. Apr 1 19:29:09 pureos kernel: [57355.028003] bq25890-charger 3-006a: Enabling OTG_EN pin Apr 1 19:29:09 pureos usbguard-daemon[680]: uid=0 pid=638 result='SUCCESS' device.rule='allow id 1d6b:0002 serial "xhci-hcd.5.auto" name "xHCI Host Controller" hash "U1nFyrkh8NpSDAU6gmicq7SQ13ff+o3bmO/lcp19jvA=" parent-hash "KXlald6eHhgVzxEC+F9GN7dshRENSCw45OyqsVHzcD8=" via-port "usb3" with-interface 09:00:00 with-connect-type ""' device.system_name='/devices/platform/soc@0/38100000.usb/xhci-hcd.5.auto/usb3' type='Device.Insert' Apr 1 19:29:09 pureos usbguard-daemon[680]: uid=0 pid=638 result='SUCCESS' device.system_name='/devices/platform/soc@0/38100000.usb/xhci-hcd.5.auto/usb3' target.new='allow' device.rule='allow id 1d6b:0002 serial "xhci-hcd.5.auto" name "xHCI Host Controller" hash "U1nFyrkh8NpSDAU6gmicq7SQ13ff+o3bmO/lcp19jvA=" parent-hash "KXlald6eHhgVzxEC+F9GN7dshRENSCw45OyqsVHzcD8=" via-port "usb3" with-interface 09:00:00 with-connect-type ""' target.old='allow' type='Policy.Device.Update' Apr 1 19:29:09 pureos usbguard-daemon[680]: uid=0 pid=638 result='SUCCESS' device.rule='allow id 1d6b:0003 serial "xhci-hcd.5.auto" name "xHCI Host Controller" hash "G/QjSJzB6wJUsQhzW88okvkIFDx1hMMGTAEgq65aNxs=" parent-hash "KXlald6eHhgVzxEC+F9GN7dshRENSCw45OyqsVHzcD8=" via-port "usb4" with-interface 09:00:00 with-connect-type ""' device.system_name='/devices/platform/soc@0/38100000.usb/xhci-hcd.5.auto/usb4' type='Device.Insert' Apr 1 19:29:09 pureos usbguard-daemon[680]: uid=0 pid=638 result='SUCCESS' device.system_name='/devices/platform/soc@0/38100000.usb/xhci-hcd.5.auto/usb4' target.new='allow' device.rule='allow id 1d6b:0003 serial "xhci-hcd.5.auto" name "xHCI Host Controller" hash "G/QjSJzB6wJUsQhzW88okvkIFDx1hMMGTAEgq65aNxs=" parent-hash "KXlald6eHhgVzxEC+F9GN7dshRENSCw45OyqsVHzcD8=" via-port "usb4" with-interface 09:00:00 with-connect-type ""' target.old='allow' type='Policy.Device.Update' Apr 1 19:29:09 pureos kernel: [57355.271992] usb 3-1: new full-speed USB device number 2 using xhci-hcd Apr 1 19:29:09 pureos kernel: [57355.429039] usb 3-1: New USB device found, idVendor=342d, idProduct=e4e6, bcdDevice= 0.05 Apr 1 19:29:09 pureos kernel: [57355.429067] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 Apr 1 19:29:09 pureos kernel: [57355.429076] usb 3-1: Product: PG-7 Apr 1 19:29:09 pureos kernel: [57355.429084] usb 3-1: Manufacturer: Hangsheng Apr 1 19:29:09 pureos kernel: [57355.430262] usb 3-1: Device is not authorized for usage Apr 1 19:29:09 pureos usbguard-daemon[680]: uid=0 pid=638 result='SUCCESS' device.rule='block id 342d:e4e6 serial "" name "PG-7" hash "ZeLRPZDRK6+H9CUEzWFW6FUweuQQ1pf69MWmW4+9wtk=" parent-hash "U1nFyrkh8NpSDAU6gmicq7SQ13ff+o3bmO/lcp19jvA=" via-port "3-1" with-interface { 03:01:01 03:00:00 03:00:00 } with-connect-type "unknown"' device.system_name='/devices/platform/soc@0/38100000.usb/xhci-hcd.5.auto/usb3/3-1' type='Device.Insert' Apr 1 19:29:09 pureos kernel: [57355.457571] input: Hangsheng PG-7 as /devices/platform/soc@0/38100000.usb/xhci-hcd.5.auto/usb3/3-1/3-1:1.0/0003:342D:E4E6.0004/input/input14 Apr 1 19:29:09 pureos kernel: [57355.606733] hid-generic 0003:342D:E4E6.0004: input,hidraw0: USB HID v1.11 Keyboard [Hangsheng PG-7] on usb-xhci-hcd.5.auto-1/input0 Apr 1 19:29:09 pureos kernel: [57355.608536] hid-generic 0003:342D:E4E6.0005: hiddev96,hidraw1: USB HID v1.11 Device [Hangsheng PG-7] on usb-xhci-hcd.5.auto-1/input1 Apr 1 19:29:09 pureos kernel: [57355.611470] input: Hangsheng PG-7 Mouse as /devices/platform/soc@0/38100000.usb/xhci-hcd.5.auto/usb3/3-1/3-1:1.2/0003:342D:E4E6.0006/input/input15 Apr 1 19:29:09 pureos kernel: [57355.611808] input: Hangsheng PG-7 System Control as /devices/platform/soc@0/38100000.usb/xhci-hcd.5.auto/usb3/3-1/3-1:1.2/0003:342D:E4E6.0006/input/input16 Apr 1 19:29:09 pureos kernel: [57355.669388] input: Hangsheng PG-7 Consumer Control as /devices/platform/soc@0/38100000.usb/xhci-hcd.5.auto/usb3/3-1/3-1:1.2/0003:342D:E4E6.0006/input/input17 Apr 1 19:29:09 pureos kernel: [57355.670136] input: Hangsheng PG-7 Keyboard as /devices/platform/soc@0/38100000.usb/xhci-hcd.5.auto/usb3/3-1/3-1:1.2/0003:342D:E4E6.0006/input/input18 Apr 1 19:29:09 pureos usbguard-daemon[680]: uid=0 pid=638 result='SUCCESS' device.system_name='/devices/platform/soc@0/38100000.usb/xhci-hcd.5.auto/usb3/3-1' target.new='allow' device.rule='block id 342d:e4e6 serial "" name "PG-7" hash "ZeLRPZDRK6+H9CUEzWFW6FUweuQQ1pf69MWmW4+9wtk=" parent-hash "U1nFyrkh8NpSDAU6gmicq7SQ13ff+o3bmO/lcp19jvA=" via-port "3-1" with-interface { 03:01:01 03:00:00 03:00:00 } with-connect-type "unknown"' target.old='block' type='Policy.Device.Update' Apr 1 19:29:09 pureos kernel: [57355.748497] hid-generic 0003:342D:E4E6.0006: input,hidraw2: USB HID v1.11 Mouse [Hangsheng PG-7] on usb-xhci-hcd.5.auto-1/input2 Apr 1 19:29:09 pureos kernel: [57355.748716] usb 3-1: authorized to connect Apr 1 19:29:09 pureos usbguard-daemon[680]: Ignoring unknown UEvent action: sysfs_devpath=/devices/platform/soc@0/38100000.usb/xhci-hcd.5.auto/usb3/3-1 action=change Apr 1 19:29:09 pureos mtp-probe: checking bus 3, device 2: "/sys/devices/platform/soc@0/38100000.usb/xhci-hcd.5.auto/usb3/3-1" Apr 1 19:29:09 pureos mtp-probe: bus: 3, device: 2 was not an MTP device Apr 1 19:29:09 pureos mtp-probe: checking bus 3, device 2: "/sys/devices/platform/soc@0/38100000.usb/xhci-hcd.5.auto/usb3/3-1" Apr 1 19:29:09 pureos mtp-probe: bus: 3, device: 2 was not an MTP device Apr 1 19:29:10 pureos upowerd[922]: treating change event as add on /sys/devices/platform/soc@0/38100000.usb/xhci-hcd.5.auto/usb3/3-1 Apr 1 19:29:10 pureos phoc[787]: [types/output/cursor.c:223] Failed to get cursor display formats Apr 1 19:29:10 pureos phoc[787]: [types/output/cursor.c:269] Failed to pick cursor format Apr 1 19:29:10 pureos phoc[787]: [types/output/cursor.c:354] Failed to render cursor buffer Apr 1 19:29:10 pureos phosh-session[7760]: The XKEYBOARD keymap compiler (xkbcomp) reports: Apr 1 19:29:10 pureos phosh-session[7760]: > Warning: Unsupported maximum keycode 569, clipping. Apr 1 19:29:10 pureos phosh-session[7760]: > X11 cannot support keycodes above 255. Apr 1 19:29:10 pureos phosh-session[7760]: Errors from xkbcomp are not fatal to the X server Apr 1 19:29:10 pureos phoc[787]: [types/output/cursor.c:223] Failed to get cursor display formats Apr 1 19:29:10 pureos phoc[787]: [types/output/cursor.c:269] Failed to pick cursor format Apr 1 19:29:10 pureos phoc[787]: [types/output/cursor.c:354] Failed to render cursor buffer Apr 1 19:29:10 pureos phosh-session[7764]: The XKEYBOARD keymap compiler (xkbcomp) reports: Apr 1 19:29:10 pureos phosh-session[7764]: > Warning: Unsupported maximum keycode 569, clipping. Apr 1 19:29:10 pureos phosh-session[7764]: > X11 cannot support keycodes above 255. Apr 1 19:29:10 pureos phosh-session[7764]: Errors from xkbcomp are not fatal to the X server Apr 1 19:29:10 pureos phoc[787]: [types/output/cursor.c:223] Failed to get cursor display formats Apr 1 19:29:10 pureos phoc[787]: [types/output/cursor.c:269] Failed to pick cursor format Apr 1 19:29:10 pureos phoc[787]: [types/output/cursor.c:354] Failed to render cursor buffer Apr 1 19:29:10 pureos phoc[787]: [types/output/cursor.c:223] Failed to get cursor display formats Apr 1 19:29:10 pureos phoc[787]: [types/output/cursor.c:269] Failed to pick cursor format Apr 1 19:29:10 pureos phoc[787]: [types/output/cursor.c:354] Failed to render cursor buffer Apr 1 19:29:10 pureos phosh-session[7766]: The XKEYBOARD keymap compiler (xkbcomp) reports: Apr 1 19:29:10 pureos phosh-session[7766]: > Warning: Unsupported maximum keycode 569, clipping. Apr 1 19:29:10 pureos phosh-session[7766]: > X11 cannot support keycodes above 255. Apr 1 19:29:10 pureos phosh-session[7766]: Errors from xkbcomp are not fatal to the X server Apr 1 19:29:10 pureos phoc[787]: [types/output/cursor.c:223] Failed to get cursor display formats Apr 1 19:29:10 pureos phoc[787]: [types/output/cursor.c:269] Failed to pick cursor format Apr 1 19:29:10 pureos phoc[787]: [types/output/cursor.c:354] Failed to render cursor buffer Apr 1 19:29:10 pureos phoc[787]: [types/output/cursor.c:223] Failed to get cursor display formats Apr 1 19:29:10 pureos phoc[787]: [types/output/cursor.c:269] Failed to pick cursor format Apr 1 19:29:10 pureos phoc[787]: [types/output/cursor.c:354] Failed to render cursor buffer Apr 1 19:29:10 pureos phosh-session[7768]: The XKEYBOARD keymap compiler (xkbcomp) reports: Apr 1 19:29:10 pureos phosh-session[7768]: > Warning: Unsupported maximum keycode 569, clipping. Apr 1 19:29:10 pureos phosh-session[7768]: > X11 cannot support keycodes above 255. Apr 1 19:29:10 pureos phosh-session[7768]: Errors from xkbcomp are not fatal to the X server --P8nCfaYFQseVLSUx-- From nobody Tue Apr 1 18:32: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 4ZRxSF1tBDz5rwV2 for ; Tue, 01 Apr 2025 18:32:29 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-ed1-f46.google.com (mail-ed1-f46.google.com [209.85.208.46]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZRxSD5724z3s7d for ; Tue, 01 Apr 2025 18:32:28 +0000 (UTC) (envelope-from asomers@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-f46.google.com with SMTP id 4fb4d7f45d1cf-5e5e8274a74so9479720a12.1 for ; Tue, 01 Apr 2025 11:32:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743532347; x=1744137147; h=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=QdjZBUj6ZNIEFpG3XsaIOmZ43Rxc7IHj+KkW2eSJVmI=; b=EU/Hh2vBZdAmdgULzAcH2InYV7gfACCaFcACnYR3EZPHU+iqKZZxqpXE5dPzvpo+Mx KP9Gz8C4GTPMWXnzl5+CPMDf8bbpQlJb7aZBwxw3q0Gv1WT0X24PzOZ1ChrdMOm3pJZK 3woMvSqbdB7tVEVGF2qcexnGBt6rLVp5OjiEDRCHBQDtxirLEE0y9TxcbA18iVaA5rS5 t9c/7f0yDXTEH7Yxr+Ez0emFsKq+fOOp68RFvoJHP0ChQ3OMKO7J5iG7lrObNYlrEzdb ZHIDVJ/u6GqpvSKVIk3N531n/hLDpdqt3KwsVL9gCuDWh7yN5osy0E3aQvYZJvNfZ+hY h7mw== X-Forwarded-Encrypted: i=1; AJvYcCXAEroVlRLM2VRxuFX+bpiNuLfLBuirsNfMbFz05d83DX+C3zaJdSsZjGBrwOVS43No38n67Xemgo4ITfh28q0=@freebsd.org X-Gm-Message-State: AOJu0Ywkn3oMWDwuX0UB76T3fsqzp2RJdRCUFAcE8W9gAOK8PJ5V4dks lzPP+KivdXrcLZs0RZsRiV1949cLQPDg6f/PQ2eXZR3z6vChxItXQI2M4uNR5/2MNtx0G/LUtHe xvl7FD1JIpbc87EeNRWqH4wLHjwVZBKMZ X-Gm-Gg: ASbGnctz/BTOF66K4sS4cgiT8W5m5wZ0Wgt+tZIw20ILxKbXT55F/k/8LJRRAVyB5MX IlelPLy36lxNCwxYCv1VL2ztSiurxKSZ67mnTx+tAnqVuS6P34HqGI5WX+1h1ciCGjRBpo3Hg1g wJcUQ/MNOSMSK9VhSG41zIw+/dITwyXvkHbIbr X-Google-Smtp-Source: AGHT+IFsFWpsp3QRQpHUUnItQEWfw1S45tczIih26+unTvhIioLkZQaMt4W5E/tNo1KN53aE0CJigUVDOis3OvL8iV8= X-Received: by 2002:a05:6402:2793:b0:5ec:939e:a60e with SMTP id 4fb4d7f45d1cf-5edfb36bf62mr11279201a12.0.1743532346878; Tue, 01 Apr 2025 11:32: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: Alan Somers Date: Tue, 1 Apr 2025 12:32:13 -0600 X-Gm-Features: AQ5f1JqD25riC1mSgN8EQAMSStr7tXyHGW2XxqccOOvGUUcEKWERVzY79niPNIs Message-ID: Subject: Re: USB keyboard Polygon 7 not recogniced To: Matthias Apitz , freebsd-current@freebsd.org Content-Type: multipart/alternative; boundary="00000000000030b24c0631bbc268" X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US] X-Rspamd-Queue-Id: 4ZRxSD5724z3s7d X-Spamd-Bar: ---- --00000000000030b24c0631bbc268 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Apr 1, 2025 at 12:22=E2=80=AFPM Matthias Apitz w= rote: > > Hello, > > My son (15 years old, Linux freak) bought for his PC such an USB > keyboard kit: https://d-r.works/products/polygon-7-keyboard-kit > (One can build the keyboard layout on own ideas.) > > It works fine on his PC connected via USB. On my beloved FreeBSD 14-CURRE= NT > it gives in /var/log/messages on attach: > > Apr 1 19:22:21 c720-1400094 kernel: ugen0.4: at usbus0 > Apr 1 19:22:21 c720-1400094 kernel: ukbd0 on uhub0 > Apr 1 19:22:21 c720-1400094 kernel: ukbd0: rev 2.00/0.05, addr 7> on usbus0 > Apr 1 19:22:21 c720-1400094 kernel: kbd2 at ukbd0 > Apr 1 19:22:21 c720-1400094 kernel: uhid0 on uhub0 > Apr 1 19:22:21 c720-1400094 kernel: uhid0: rev 2.00/0.05, addr 7> on usbus0 > Apr 1 19:22:21 c720-1400094 kernel: ums0 on uhub0 > Apr 1 19:22:21 c720-1400094 kernel: ums0: 2.00/0.05, addr 7> on usbus0 > Apr 1 19:22:21 c720-1400094 kernel: ums0: 8 buttons and [XYZT] > coordinates ID=3D2 > > But no keypress is visible in any terminal. > > I will attach as well, what my Debian Linux cellular says on attache and > there > it works fine too. > > The idVendor=3D1d6b and idProduct=3D0002 visible in /var/log/syslog in De= bian > are not > shown in FreeBSD. Perhaps we miss them in our driver? > > matthias > > -- > Matthias Apitz, =E2=9C=89 guru@unixarea.de, http://www.unixarea.de/ > +49-176-38902045 > Public GnuPG key: http://www.unixarea.de/key.pub > Some fancy keyboards are technically combination keyboard/mouse devices. FreeBSD's standard keyboard driver still doesn't support them, but the usbhid driver does. Just add this to your /boot/loader.conf: usbhid_load=3D"YES" hw.usb.usbhid.enable=3D1 --00000000000030b24c0631bbc268 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Apr 1, 2025 at 12:22=E2=80=AFPM Matth= ias Apitz <guru@unixarea.de> = wrote:

Hello,

My son (15 years old, Linux freak) bought for his PC such an USB
keyboard kit: https://d-r.works/products/polygon-7-= keyboard-kit
(One can build the keyboard layout on own ideas.)

It works fine on his PC connected via USB. On my beloved FreeBSD 14-CURRENT=
it gives in /var/log/messages on attach:

Apr=C2=A0 1 19:22:21 c720-1400094 kernel: ugen0.4: <Hangsheng PG-7> a= t usbus0
Apr=C2=A0 1 19:22:21 c720-1400094 kernel: ukbd0 on uhub0
Apr=C2=A0 1 19:22:21 c720-1400094 kernel: ukbd0: <Hangsheng PG-7, class = 0/0, rev 2.00/0.05, addr 7> on usbus0
Apr=C2=A0 1 19:22:21 c720-1400094 kernel: kbd2 at ukbd0
Apr=C2=A0 1 19:22:21 c720-1400094 kernel: uhid0 on uhub0
Apr=C2=A0 1 19:22:21 c720-1400094 kernel: uhid0: <Hangsheng PG-7, class = 0/0, rev 2.00/0.05, addr 7> on usbus0
Apr=C2=A0 1 19:22:21 c720-1400094 kernel: ums0 on uhub0
Apr=C2=A0 1 19:22:21 c720-1400094 kernel: ums0: <Hangsheng PG-7, class 0= /0, rev 2.00/0.05, addr 7> on usbus0
Apr=C2=A0 1 19:22:21 c720-1400094 kernel: ums0: 8 buttons and [XYZT] coordi= nates ID=3D2

But no keypress is visible in any terminal.

I will attach as well, what my Debian Linux cellular says on attache and th= ere
it works fine too.

The idVendor=3D1d6b and idProduct=3D0002 visible in /var/log/syslog in Debi= an are not
shown in FreeBSD. Perhaps we miss them in our driver?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 matthias

--
Matthias Apitz, =E2=9C=89 guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub

Some fancy keyboards are techni= cally combination keyboard/mouse devices.=C2=A0 FreeBSD's standard keyb= oard driver still doesn't support them, but the usbhid driver does.=C2= =A0 Just add this to your /boot/loader.conf:

usbhi= d_load=3D"YES"
hw.usb.usbhid.enable=3D1
--00000000000030b24c0631bbc268-- From nobody Tue Apr 1 19:54: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 4ZRzH36KxSz5s2Lx for ; Tue, 01 Apr 2025 19:54:39 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZRzH34JfMz3HQs; Tue, 01 Apr 2025 19:54:39 +0000 (UTC) (envelope-from guru@unixarea.de) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=unixarea.de ; s=blu3434000; h=In-Reply-To:Content-Transfer-Encoding:Content-Type: MIME-Version:References:Reply-To:Message-ID:Subject:Cc:To:From:Date:Sender: Content-ID:Content-Description; bh=5tjwYK4DgGbrCklwh4cteCtilCZev24QlGbNqBCAeNc=; b=cQqJUKeu31YRPDKh536Wpdlsi0 nxtUVTgHbg6LkUIlWz7SDSL3nIAVJ/9Lnmx1ZM4MYsmCTTo/gAECnJGMY6tzMpnIbKZFjsw+BEH7T mX9yR8B9ZGIFRfA/xbXND0xomo6nLUfWooNK49xbfPvP8FVGmgXxt4tpN8HBixFYJtbieKrou+6Qt jhtpw3165SaNygxchQsVRWqUhMcXBFu/Yll4KIKDD3dRtVCVIFtsdxb3GcXx8VruzMp3wvEornhQN FpZqYEMe3zxK450Pgd3xaEMy6qrVtOj6zeBbHx29S4XP+GQsZvhSFz1V0T7URwPL8sX5vRhec9AEM kHRHTPwQ==; Received: from [62.216.207.69] (helo=localhost.unixarea.de) by ms-10.1blu.de with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1tzhgz-002cRj-FG; Tue, 01 Apr 2025 21:54:37 +0200 Received: from localhost.my.domain (c720-1400094 [127.0.0.1]) by localhost.unixarea.de (8.17.1/8.14.9) with ESMTP id 531Jsbgg003438; Tue, 1 Apr 2025 21:54:37 +0200 (CEST) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.17.1/8.14.9/Submit) id 531Jsaki003437; Tue, 1 Apr 2025 21:54:36 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Tue, 1 Apr 2025 21:54:36 +0200 From: Matthias Apitz To: Alan Somers Cc: freebsd-current@freebsd.org Subject: Re: USB keyboard Polygon 7 not recogniced Message-ID: Reply-To: Matthias Apitz Mail-Followup-To: Alan Somers , freebsd-current@freebsd.org 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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Operating-System: FreeBSD 14.0-CURRENT r1400094 (amd64) X-message-flag: Mails in HTML will not be read! Please, only plain text. X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 62.216.207.69 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:42730, ipnet:178.254.0.0/19, country:DE] X-Rspamd-Queue-Id: 4ZRzH34JfMz3HQs X-Spamd-Bar: ---- El día martes, abril 01, 2025 a las 12:32:13p. m. -0600, Alan Somers escribió: > Some fancy keyboards are technically combination keyboard/mouse devices. > FreeBSD's standard keyboard driver still doesn't support them, but the > usbhid driver does. Just add this to your /boot/loader.conf: > > usbhid_load="YES" > hw.usb.usbhid.enable=1 Thanks! It works fine. matthias -- Matthias Apitz, ✉ guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub From nobody Tue Apr 1 23:08:46 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 4ZS3bK2Q82z5sFtM for ; Tue, 01 Apr 2025 23:09:01 +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 4ZS3bJ1v8Tz3gJb for ; Tue, 01 Apr 2025 23:09:00 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=GZWPkyrI; 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-5e535e6739bso9927577a12.1 for ; Tue, 01 Apr 2025 16:09:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1743548939; x=1744153739; 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=ehcAXHJ+06dMlp9tyzgEJOft2+b8hXqwmZcWC+Q6vaM=; b=GZWPkyrIAN4lZ+9ABV+aKNeTTSHzkYIygEFp+mYd4RWLUOwpXnqdGDxmVSzBCybObw eJ+kNhstGDNzWcMx1+ceMSqwBel8ujVuM/fxHufXbaGbhDuilE1pPp3jJYB25+REA/3h 2xHrMFJGwEbAdXrfC86iKUb53aQ04hvT5dLyOQezH+siyBS3E/3hpK6ifmtM8hCgvlIp Vu+1Wt/lyJv8jERJwCKDQvnOJwwE6Px9R+nvW2XHMLfZ4FoYWEGf1LSFHg+qIo/HzPqw EycplmA/zATbCP9dk3KtkcjDPeBtILwuKJhtb+mbHj0MYe9HFp44W9y+DkJowdt6rV8a cs2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743548939; x=1744153739; 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=ehcAXHJ+06dMlp9tyzgEJOft2+b8hXqwmZcWC+Q6vaM=; b=tY/34DShnH4aghfd6F4u/pO0turCgFJdwOF2UUnqw8JXRNq/NGE6sRLf9MTVLqBO/H KnkfOvf0v8hikxVUFiVs/Gcl001oeyqO5EV+kCTh4wh4K8D6c8X6UNRI9NBvUtMcAFAX li0UHc/knHrAwgEyn/B+NSzWIzty+H/Fdz4NZLGc5omIrdmiN/IdqmsK6up7CJ/dqaFc 7upLxKx3Z7kOT5cnhdTT1avEIdaqOlFT07kHOyXdN/Fuc/mt1HM+DuKBaErmU4JZjL3A 3drJKD36ETTGyk2W1wTjt0uK0fTD1NVb/5RxGJ3whs0RdM/VzrofQ5VNwk7FxT49VfLB JlQA== X-Forwarded-Encrypted: i=1; AJvYcCViwSQdOSjhBJpM2jV8S/wTAnxpOPHK6o0SlzKq48KR5YX107+igp17hB3KCtUJbMHItCa3ATCdTBibEjBvi+w=@freebsd.org X-Gm-Message-State: AOJu0Yzieth8tSk3IWkNrP4kOvyb+C1urWj1Cb2bsP5PloEOWpwmt/rw OoLvPcQJO5H/NUt2synGfSXCVikpRDalEgCbu7RnY89PNK3dkcHWXYdDwSFvELLiaGQXJ9DBdWr 4sgW3NlZfhzonyXA9YENORtKWFan234g= X-Gm-Gg: ASbGncsY5Ml2s5rRo6aZgg7bgUi/FjHKNVD+oz2tZ/sx1ZTEHXWgXsH7JijaHBHVZ2p 3W5TAwZASdyfbUSF2gcIA7soEHSJ/dF4UFSWmA+XTPVXAD7paS8qLUvqyfnXiqlvvPGHYhDr385 LkA1/TVEpLeNqFUiOvOXwZ0UGsXK1kUwceHvVkfUAuGkzWHs9V4DO/P6VGoA== X-Google-Smtp-Source: AGHT+IEj629qnRUwKFbxgaTYP2Eci6lwDeul0tLSuI8s4/HwuoWss0Tg8JRHzUQBplgSJhnD6q93KqnB9F0NQyHTS2M= X-Received: by 2002:a05:6402:c4a:b0:5e4:d2c9:455c with SMTP id 4fb4d7f45d1cf-5edfceaa4c0mr14141885a12.10.1743548938217; Tue, 01 Apr 2025 16:08:58 -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: Tue, 1 Apr 2025 16:08:46 -0700 X-Gm-Features: AQ5f1JrJ2Jr2KJPwhjYh-_PbLFXzry7LodvuH4li2E-J9ok_2tmgylEe7OZhyLU 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-Spamd-Result: default: False [1.13 / 15.00]; NEURAL_SPAM_MEDIUM(0.90)[0.899]; NEURAL_SPAM_LONG(0.72)[0.719]; NEURAL_SPAM_SHORT(0.51)[0.510]; 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]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TAGGED_FROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_SOME(0.00)[]; ARC_NA(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::532:from]; MID_RHS_MATCH_FROMTLD(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; MISSING_XM_UA(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; FREEMAIL_ENVFROM(0.00)[gmail.com] X-Rspamd-Queue-Id: 4ZS3bJ1v8Tz3gJb X-Spamd-Bar: + On Sat, Mar 29, 2025 at 1:22=E2=80=AFPM Rick Macklem wrote: > > 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= that's > > > > > > taken care of. FreeBSD's tar(1) has supported extended attribut= es > > > > > > 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 prob= ably needs > > > > > to be tweaked to use the different syscall API so that it can han= dle 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. Bu= t, > > > > yeah, if FreeBSD makes changes to how extended attributes work, I o= r > > > > 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-appli= cation > > > > > > basis. That's why we added support to libarchive: so we can shi= p > > > > > > 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 t= hey > > > handle user space only. (system space will still work, but only via t= he > > > 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. I have put the VFS/syscall changes up in phabricator under D49583. I listed a few reviewers, but anyone is welcome to review/comment on it. rick > Also, there ahs not been much response related to the question "should th= is > 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 els= e. > (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= /03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc From nobody Wed Apr 2 04:42:31 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 4ZSC0G2zMWz5rPnc for ; Wed, 02 Apr 2025 04:42:38 +0000 (UTC) (envelope-from sgharms@stevengharms.com) Received: from mail-24420.protonmail.ch (mail-24420.protonmail.ch [109.224.244.20]) (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 4ZSC0F1Th5z3ptn for ; Wed, 02 Apr 2025 04:42:37 +0000 (UTC) (envelope-from sgharms@stevengharms.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=stevengharms.com header.s=protonmail header.b=HZ6cx93W; dmarc=none; spf=pass (mx1.freebsd.org: domain of sgharms@stevengharms.com designates 109.224.244.20 as permitted sender) smtp.mailfrom=sgharms@stevengharms.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stevengharms.com; s=protonmail; t=1743568954; x=1743828154; bh=r6s3sKyGNIbroUGdhVMQJ35djPXQ/VyQ7rLGZh3zBFA=; 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=HZ6cx93WHDLvhLGpPxRwFcsArMs6NfvYHGEcq9jgbHoXjm3Usqqv4WcR6dBeujcOv DGcHz6jArGx4CWcmdyX3CB2FdADMaT/Wr+5KyjALb/DCCQ+89Ung8+V0vRoo8yO2wF vNp5k21dgAGaey0gK68ENMIgGCi9x+fpnynuaEVg= Date: Wed, 02 Apr 2025 04:42:31 +0000 To: "freebsd-current@freebsd.org" From: "Steven Harms (High-Security Mail)" Subject: =?utf-8?Q?/var/crash/vmcore.*=5Fnot=5Fpresent=5F(was:=5FKernel=5Fpanic=5F_on_HEAD_=E2=80=A6)?= Message-ID: Feedback-ID: 16996530:user:proton X-Pm-Message-ID: e02b4b022ecf42832164acd286bff8b53d905b19 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=_UPEBycmU5x7AWDjmBkrq9Xra98maBgElaCkaHz0qwQ" X-Spamd-Result: default: False [-1.82 / 15.00]; RBL_SENDERSCORE_REPUT_9(-1.00)[109.224.244.20:from]; MIME_BASE64_TEXT_BOGUS(1.00)[]; NEURAL_HAM_MEDIUM(-0.95)[-0.945]; NEURAL_HAM_SHORT(-0.84)[-0.836]; NEURAL_SPAM_LONG(0.36)[0.358]; 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)[]; ASN(0.00)[asn:29676, ipnet:109.224.244.0/22, country:GB]; MISSING_XM_UA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FROM_EQ_ENVFROM(0.00)[]; DMARC_NA(0.00)[stevengharms.com]; TO_DN_EQ_ADDR_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@FreeBSD.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_ZERO(0.00)[0]; ARC_NA(0.00)[]; DKIM_TRACE(0.00)[stevengharms.com:+] X-Rspamd-Queue-Id: 4ZSC0F1Th5z3ptn X-Spamd-Bar: - --b1=_UPEBycmU5x7AWDjmBkrq9Xra98maBgElaCkaHz0qwQ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 R3JhaGFtIGV0IGFsLiwKCiMgbHNibGsgL2Rldi9hZGEwCkRFVklDRSBNQUo6TUlOIFNJWkUgVFlQ RSBMQUJFTCBNT1VOVAphZGEwIDA6OTQgMTE5RyBHUFQgLSAtCmFkYTBwMSAwOjk1IDI2ME0gZWZp IGdwdC9lZmlib290MCAvYm9vdC9lZmkKYWRhMHAyIDA6OTYgNTEySyBmcmVlYnNkLWJvb3QgZ3B0 L2dwdGJvb3QwIC0KPEZSRUU+IC06LSA0OTJLIC0gLSAtCmFkYTBwMyAwOjk3IDIuMEcgZnJlZWJz ZC1zd2FwIGdwdC9mcmVlYnNkLXN3YXAgU1dBUAphZGEwcDQgMDo5OCAxMTdHIGZyZWVic2QtemZz IGdwdC9mcmVlYnNkLXpmcyA8WkZTPiA8RlJFRT4gLTotIDMyNEsgLQoKVGhhdCBpbXBsaWVzIHRv IG1lIHRoYXQgbGFiZWwgZnJlZWJzZC1zd2FwIHNob3VsZCBoYXZlIGFueSBjcmFzaGVzIHdoZW4g ZHVtcGRldj1BVVRPLiBBbSBJIG1pc3Rha2VuPwoKIyBnZWxpIGxpc3QgPT0+IHN1Z2dlc3RlZCBJ IHRyeSBnZWxpIGxvYWQgZmlyc3Q/IEkgZGlkCiMgZ2VsaSBsaXN0ID09PiBub3RoaW5nCgpUaGFu a3MsCgpTdGV2ZW4KLS0tCgpQdWJsaWMgS2V5OiAyMkJFMzlFMkZBNjhEOEJBOERDNEI0M0E1NUEx NkQ4Q0UyQjAzNkRFCgpNZXNzYWdlcyBmcm9tIHRoaXMgYWNjb3VudCBhcmUgY29uc2lkZXJlZCB0 aGUgYmVzdC1zZWN1cmVkIGFuZCBtb3N0IHJlbGlhYmxlLiBTZW5kIGluZm9ybWF0aW9uIHJlZ2Fy ZGluZyBoZWFsdGgsIHdlYWx0aCwgb3IgcmVxdWlyaW5nIGhpZ2hlciBzdGFuZGFyZHMgb2Ygc2Vj dXJpdHkgdG8gdGhpcyBhZGRyZXNzLgoKU2VudCB3aXRoIFtQcm90b24gTWFpbF0oaHR0cHM6Ly9w cm90b24ubWUvbWFpbC9ob21lKSBzZWN1cmUgZW1haWwu --b1=_UPEBycmU5x7AWDjmBkrq9Xra98maBgElaCkaHz0qwQ Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0 cHg7Ij5HcmFoYW0gZXQgYWwuLDxicj48YnI+PHNwYW4+Jm5ic3A7IyBsc2JsayAvZGV2L2FkYTA8 L3NwYW4+PGRpdj48c3Bhbj5ERVZJQ0UgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IE1BSjpN SU4gU0laRSBUWVBFICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7TEFCRUwgTU9VTlQ8L3NwYW4+PC9kaXY+PGRpdj48c3Bh bj5hZGEwICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDA6OTQgJm5i c3A7MTE5RyBHUFQgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAtIC08L3NwYW4+PC9kaXY+PGRp dj48c3Bhbj4mbmJzcDsgYWRhMHAxICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAwOjk1ICZu YnNwOzI2ME0gZWZpICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7Z3B0L2VmaWJvb3QwIC9ib290L2VmaTwvc3Bhbj48L2Rpdj48ZGl2PjxzcGFuPiZuYnNwOyBh ZGEwcDIgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDA6OTYgJm5ic3A7NTEySyBmcmVlYnNk LWJvb3QgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IGdwdC9ncHRib290MCAtPC9zcGFuPjwvZGl2PjxkaXY+PHNwYW4+ Jm5ic3A7ICZsdDtGUkVFJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgLTotICZuYnNw OyA0OTJLIC0gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgLSAtPC9zcGFuPjwvZGl2 PjxkaXY+PHNwYW4+Jm5ic3A7IGFkYTBwMyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgMDo5 NyAmbmJzcDsyLjBHIGZyZWVic2Qtc3dhcCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGdwdC9mcmVlYnNkLXN3YXAgU1dBUDwvc3Bhbj48L2Rp dj48ZGl2PjxzcGFuPiZuYnNwOyBhZGEwcDQgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDA6 OTggJm5ic3A7MTE3RyBmcmVlYnNkLXpmcyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBncHQvZnJlZWJzZC16ZnMgJmx0O1pGUyZn dDs8L3NwYW4+PC9kaXY+PHNwYW4+Jm5ic3A7ICZsdDtGUkVFJmd0OyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgLTotICZuYnNwOyAzMjRLIC0gJm5ic3A7IDwvc3Bhbj48YnI+PC9kaXY+PGRp diBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7 Ij48YnI+PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBm b250LXNpemU6IDE0cHg7Ij5UaGF0IGltcGxpZXMgdG8gbWUgdGhhdCBsYWJlbCBmcmVlYnNkLXN3 YXAgc2hvdWxkIGhhdmUgYW55IGNyYXNoZXMgd2hlbiBkdW1wZGV2PUFVVE8uIEFtIEkgbWlzdGFr ZW4/PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBmb250 LXNpemU6IDE0cHg7Ij48YnI+PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBz YW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4jIGdlbGkgbGlzdCA9PSZndDsgc3VnZ2VzdGVk IEkgdHJ5IGdlbGkgbG9hZCBmaXJzdD8gSSBkaWQ8L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWls eTogQXJpYWwsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPiMgZ2VsaSBsaXN0ID09Jmd0 OyBub3RoaW5nPC9kaXY+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlm OyBmb250LXNpemU6IDE0cHg7Ij48YnI+PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IEFy aWFsLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij5UaGFua3MsPC9kaXY+PGRpdiBzdHls ZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij48YnI+ PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBmb250LXNp emU6IDE0cHg7Ij5TdGV2ZW48L2Rpdj4NCjxkaXYgY2xhc3M9InByb3Rvbm1haWxfc2lnbmF0dXJl X2Jsb2NrIiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBmb250LXNpemU6 IDE0cHg7Ij4NCiAgICA8ZGl2IGNsYXNzPSJwcm90b25tYWlsX3NpZ25hdHVyZV9ibG9jay11c2Vy Ij4NCiAgICAgICAgPGRpdj4tLS08YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdiBzdHlsZT0i Zm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7IGNvbG9yOiBy Z2IoMCwgMCwgMCk7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsiPlB1Ymxp YyBLZXk6IDxhIHRpdGxlPSIyMkJFMzlFMkZBNjhEOEJBOERDNEI0M0E1NUExNkQ4Q0UyQjAzNkRF IiBocmVmPSJodHRwczovLzIyQkUzOUUyRkE2OEQ4QkE4REM0QjQzQTU1QTE2RDhDRTJCMDM2REUi PjxzcGFuPjIyQkUzOUUyRkE2OEQ4QkE4REM0QjQzQTU1QTE2RDhDRTJCMDM2REU8L3NwYW4+PC9h Pjxicj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBu b3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJh bnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgdGV4 dC1kZWNvcmF0aW9uOiBub25lOyBmb250LWZhbWlseTogQXJpYWwsIEhlbHZldGljYSwgc2Fucy1z ZXJpZjsgY29sb3I6IHJnYigzNCwgMzQsIDM0KTsiPjxicj48L2Rpdj48ZGl2Pk1lc3NhZ2VzIGZy b20gdGhpcyBhY2NvdW50IGFyZSBjb25zaWRlcmVkIHRoZSBiZXN0LXNlY3VyZWQgYW5kIG1vc3Qg cmVsaWFibGUuIFNlbmQgaW5mb3JtYXRpb24gcmVnYXJkaW5nIGhlYWx0aCwgd2VhbHRoLCBvciBy ZXF1aXJpbmcgaGlnaGVyIHN0YW5kYXJkcyBvZiBzZWN1cml0eSB0byB0aGlzIGFkZHJlc3MuPGJy PjwvZGl2Pg0KICAgIDwvZGl2Pg0KICAgIDxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwg c2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+PGJyPjwvZGl2Pg0KICAgIDxkaXYgY2xhc3M9 InByb3Rvbm1haWxfc2lnbmF0dXJlX2Jsb2NrLXByb3RvbiI+DQogICAgICAgIFNlbnQgd2l0aCA8 YSB0YXJnZXQ9Il9ibGFuayIgaHJlZj0iaHR0cHM6Ly9wcm90b24ubWUvbWFpbC9ob21lIj5Qcm90 b24gTWFpbDwvYT4gc2VjdXJlIGVtYWlsLg0KICAgIDwvZGl2Pg0KPC9kaXY+DQo= --b1=_UPEBycmU5x7AWDjmBkrq9Xra98maBgElaCkaHz0qwQ-- From nobody Wed Apr 2 05:23:22 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 4ZSCvS1hmSz5rSWP for ; Wed, 02 Apr 2025 05:23:32 +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 4ZSCvP5kQqz3tZ5 for ; Wed, 02 Apr 2025 05:23:29 +0000 (UTC) (envelope-from sgharms@stevengharms.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=stevengharms.com header.s=protonmail header.b=kvwqdrq5; 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=1743571406; x=1743830606; bh=4iN3BoUc/2IMlx1KhaFLukDN/iRmFi3fW561uGIuFqY=; 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=kvwqdrq5NmfUm44VnkOAtRU0RQKGmRX7zMeWJ8ddZvwBDoR5WGRsqV8JIyQ+3yNZu 3C5MOa9l/7vnTHiVYV5eXq1gpkUzrxtjYTtK07aipCWiDRASMzQhS+aBFhU8k+G0I2 hltuDRZvVmy3ln8O1RlnAtNOW2pIgPLKygP5YNWI= Date: Wed, 02 Apr 2025 05:23:22 +0000 To: "freebsd-current@freebsd.org" From: "Steven Harms (High-Security Mail)" Subject: Logged Blank at kernel panic (?) (WAS: Re: Kernel panic on HEAD (93cf4310 2025-03-28)) Message-ID: <1M48yy09C3z85rk72AgFB_MYJ28ODexPUbUwlhRoxSGCLVdQVRmPzgOz_j_Oqj-u-suIcu-BjBwyVNBUh88xY6b3e_1Nd9v2EoOunXivtO0=@stevengharms.com> Feedback-ID: 16996530:user:proton X-Pm-Message-ID: e4a549ae08b7c923d0ffba20004f8da28eb50687 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=_WUWKov9a0PDExS23HEkfpvymFw96XSXd8sybMuTCl4" X-Spamd-Result: default: False [-4.26 / 15.00]; RBL_SENDERSCORE_REPUT_9(-1.00)[109.224.244.22:from]; NEURAL_HAM_SHORT(-0.99)[-0.989]; NEURAL_HAM_LONG(-0.95)[-0.949]; NEURAL_HAM_MEDIUM(-0.92)[-0.923]; 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)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:62371, ipnet:109.224.244.0/24, country:CH]; MISSING_XM_UA(0.00)[]; ARC_NA(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_ZERO(0.00)[0]; TO_DN_EQ_ADDR_ALL(0.00)[]; DMARC_NA(0.00)[stevengharms.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@FreeBSD.org]; DKIM_TRACE(0.00)[stevengharms.com:+] X-Rspamd-Queue-Id: 4ZSCvP5kQqz3tZ5 X-Spamd-Bar: ---- --b1=_WUWKov9a0PDExS23HEkfpvymFw96XSXd8sybMuTCl4 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 V2l0aCBzb21lIGFkZGl0aW9uYWwgaW5zaWdodHMgSSBjYW4gYWRkOgoKLSBJIGNhbiBib290IGlu IHNpbmdsZSB1c2VyIG9uIDE1LjAtQ1VSUkVOVCAoVGhhbmtzIERhdmUgQy4gZm9yIHRoZSBpZGVh KS4gV2UncmUgZGVmaW5pdGVseSBnZXR0aW5nIHRvIHJ1bm5pbmcgdGhlIHJjJ3MgYW5kIGl0J3Mg c29tZXRoaW5nIHRoYXQgYnJlYWtzIGFib3V0IHRoZSB0aW1lIC9ldGMvcmMuZC9kZXZtYXRjaCBz dGFydHMKCi0gQXQgcHJlc2VudCB0aGVyZSBhcmUgbm8gbW9kdWxlIGxvYWRzIGluIC9ldGMvcmMu Y29uZjoga2xkX2xpc3QgaXMgY29tbWVudGVkLW91dAotIEl0IHNlZW1zIGxpa2UgdGhlIGN1dCBv ZmYgaXMgd2hlbiB0aGUga2VybmVsIHN0YXJ0cyB3b3JraW5nIHdpdGggdGhlICdobXMnIHN1YnN5 c3RlbSAoc2VlIGJlbG93KQoKSSB3YXMgYWJsZSB0byBnZXQgdGhlIHBhbmljIG91dHB1dCBmcm9t IG1lc3NhZ2VzIC0tIGJ1dCB0aGVyZSdzIG5vICJoZXJlJ3Mgd2hlcmUgd2UgZmFpbGVkLCIgQUZB SUNULiBIYXZlIEkgZ290dGVuIGFsbCB0aGUgdXNlZnVsIGRlYnVnZ2luZyBtZXNzYWdlcyBhdCB0 aGlzIHBvaW50PwoKVGhhbmtzIGZvciBoZWxwLiBIb3BlZnVsbHkgdXNlZnVsIGxvZyBkYXRhIGFy ZSBiZWxvdy4KClN0ZXZlbgoKPT09IFBBTklDID09PQoKQXByIDIgMDQ6MTY6MjcgZnJlZWJzZCBr ZXJuZWw6IGlpY2hpZDA6IDxERUxMMDczQjowMCAwNkNCOjdFN0UgSTJDIEhJRCBkZXZpY2U+IGF0 IGFkZHIgMHgyYyBpcnEgNTEgb24gaWljYnVzMApBcHIgMiAwNDoxNjoyNyBmcmVlYnNkIGtlcm5l bDogaGlkYnVzMDogPEhJRCBidXM+IG9uIGlpY2hpZDAKQXByIDIgMDQ6MTY6MjcgZnJlZWJzZCBr ZXJuZWw6CkFwciAyIDA0OjE2OjI3IGZyZWVic2Qgc3lzbG9nZDogbGFzdCBtZXNzYWdlIHJlcGVh dGVkIDEgdGltZXMKQXByIDIgMDQ6MTY6MjcgZnJlZWJzZCBrZXJuZWw6IEZhdGFsIHRyYXAgMTI6 IHBhZ2UgZmF1bHQgd2hpbGUgaW4ga2VybmVsIG1vZGUKQXByIDIgMDQ6MTY6MjcgZnJlZWJzZCBr ZXJuZWw6IGNwdWlkID0gMDsgYXBpYyBpZCA9IDAwCkFwciAyIDA0OjE2OjI3IGZyZWVic2Qga2Vy bmVsOiBmYXVsdCB2aXJ0dWFsIGFkZHJlc3MgPSAweDAKQXByIDIgMDQ6MTY6MjcgZnJlZWJzZCBr ZXJuZWw6IGZhdWx0IGNvZGUgPSBzdXBlcnZpc29yIHJlYWQgaW5zdHJ1Y3Rpb24sIHBhZ2Ugbm90 IHByZXNlbnQKQXByIDIgMDQ6MTY6MjcgZnJlZWJzZCBrZXJuZWw6IGluc3RydWN0aW9uIHBvaW50 ZXIgPSAweDIwOjB4MApBcHIgMiAwNDoxNjoyNyBmcmVlYnNkIGtlcm5lbDogc3RhY2sgcG9pbnRl ciA9IDB4Mjg6MHhmZmZmZmUwMDY4ZGZjZTM4CkFwciAyIDA0OjE2OjI3IGZyZWVic2Qga2VybmVs OiBmcmFtZSBwb2ludGVyID0gMHgyODoweGZmZmZmZTAwNjhkZmNlNjAKQXByIDIgMDQ6MTY6Mjcg ZnJlZWJzZCBrZXJuZWw6IGNvZGUgc2VnbWVudCA9IGJhc2UgMHgwLCBsaW1pdCAweGZmZmZmLCB0 eXBlIDB4MWIKQXByIDIgMDQ6MTY6MjcgZnJlZWJzZCBrZXJuZWw6ID0gRFBMIDAsIHByZXMgMSwg bG9uZyAxLCBkZWYzMiAwLCBncmFuIDEKQXByIDIgMDQ6MTY6MjcgZnJlZWJzZCBrZXJuZWw6IHBy b2Nlc3NvciBlZmxhZ3MgPSBpbnRlcnJ1cHQgZW5hYmxlZCwgcmVzdW1lLCBJT1BMID0gMAoKLSBJ J20gc3VycHJpc2VkIGJ5IHRoZSAiYmxhbmsgbGlrZSIgcmVwZWF0ZWQgMSB0aW1lcwotIFRoaXMg cG9ydGlvbiBvZiB0aGUgdHJhY2UgZGlkbid0IHJlYWxseSBoZWxwIG1lLCBidXQgdGhlc2UgY2Fs bCBzdGFja3Mgc2VlbWVkIGludGVyZXN0aW5nIHRvbwoKSW50ZXJlc3Rpbmcgc3RhY2sgZGF0YT8K CkFwciAyIDA0OjE2OjI3IGZyZWVic2Qga2VybmVsOiBLREI6IHN0YWNrIGJhY2t0cmFjZToKQXBy IDIgMDQ6MTY6MjcgZnJlZWJzZCBrZXJuZWw6IGRiX3RyYWNlX3NlbGZfd3JhcHBlcigpIGF0IGRi X3RyYWNlX3NlbGZfd3JhcHBlcisweDJiL2ZyYW1lIDB4ZmZmZmZlMDA2OGRmY2I2MApBcHIgMiAw NDoxNjoyNyBmcmVlYnNkIGtlcm5lbDogdnBhbmljKCkgYXQgdnBhbmljKzB4MTM2L2ZyYW1lIDB4 ZmZmZmZlMDA2OGRmY2M5MApBcHIgMiAwNDoxNjoyNyBmcmVlYnNkIGtlcm5lbDogcGFuaWMoKSBh dCBwYW5pYysweDQzL2ZyYW1lIDB4ZmZmZmZlMDA2OGRmY2NmMApBcHIgMiAwNDoxNjoyNyBmcmVl YnNkIGtlcm5lbDogdHJhcF9wZmF1bHQoKSBhdCB0cmFwX3BmYXVsdCsweDQ2Ni9mcmFtZSAweGZm ZmZmZTAwNjhkZmNkNjAKQXByIDIgMDQ6MTY6MjcgZnJlZWJzZCBrZXJuZWw6IGNhbGx0cmFwKCkg YXQgY2FsbHRyYXArMHg4L2ZyYW1lIDB4ZmZmZmZlMDA2OGRmY2Q2MApBcHIgMiAwNDoxNjoyNyBm cmVlYnNkIGtlcm5lbDogLS0tIHRyYXAgMHhjLCByaXAgPSAwLCByc3AgPSAweGZmZmZmZTAwNjhk ZmNlMzgsIHJicCA9IDB4ZmZmZmZlMDA2OGRmY2U2MCAtLS0KQXByIDIgMDQ6MTY6MjcgZnJlZWJz ZCBrZXJuZWw6ID8/KCkgYXQgMC9mcmFtZSAweGZmZmZmZTAwNjhkZmNlNjAKQXByIDIgMDQ6MTY6 MjcgZnJlZWJzZCBrZXJuZWw6IGl0aHJlYWRfbG9vcCgpIGF0IGl0aHJlYWRfbG9vcCsweDI2Ni9m cmFtZSAweGZmZmZmZTAwNjhkZmNlZjAKQXByIDIgMDQ6MTY6MjcgZnJlZWJzZCBrZXJuZWw6IGZv cmtfZXhpdCgpIGF0IGZvcmtfZXhpdCsweDgyL2ZyYW1lIDB4ZmZmZmZlMDA2OGRmY2YzMApBcHIg MiAwNDoxNjoyNyBmcmVlYnNkIGtlcm5lbDogZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFt cG9saW5lKzB4ZS9mcmFtZSAweGZmZmZmZTAwNjhkZmNmMzAKQXByIDIgMDQ6MTY6MjcgZnJlZWJz ZCBrZXJuZWw6IC0tLSB0cmFwIDAsIHJpcCA9IDAsIHJzcCA9IDB4MSwgcmJwID0gMHgzNTAxM2Zj NWVhNDQgLS0tQXByIDIgMDQ6MTY6MjcgZnJlZWJzZCBrZXJuZWw6IEtEQjogZW50ZXI6IHBhbmlj Cgo9PT09IFVzaW5nIG15IG9sZCwgc3RhYmxlIGtlcm5lbDo9PT0KCkhlcmUncyB3aGF0IGNvbWVz IG5leHQ6CgpNYXIgMTYgMjE6NDM6MjEgZnJlZWJzZCBrZXJuZWw6IGlpY2hpZDA6IDxERUxMMDcz QjowMCAwNkNCOjdFN0UgSTJDIEhJRCBkZXZpY2U+IGF0IGFkZHIgMHgyYyBpcnEgNTEgb24gaWlj YnVzMApNYXIgMTYgMjE6NDM6MjEgZnJlZWJzZCBrZXJuZWw6IGhpZGJ1czA6IDxISUQgYnVzPiBv biBpaWNoaWQwCk1hciAxNiAyMTo0MzoyMSBmcmVlYnNkIGtlcm5lbDogaG1zMDogPERFTEwwNzNC OjAwIDA2Q0I6N0U3RSBNb3VzZT4gb24gaGlkYnVzMApNYXIgMTYgMjE6NDM6MjEgZnJlZWJzZCBr ZXJuZWw6IGhtczA6IDIgYnV0dG9ucyBhbmQgW1hZXSBjb29yZGluYXRlcyBJRD0yCk1hciAxNiAy MTo0MzoyMSBmcmVlYnNkIGtlcm5lbDogaG10MDogPERFTEwwNzNCOjAwIDA2Q0I6N0U3RSBUb3Vj aFBhZD4gb24gaGlkYnVzMApNYXIgMTYgMjE6NDM6MjEgZnJlZWJzZCBrZXJuZWw6IGhjb25mMDog PERFTEwwNzNCOjAwIDA2Q0I6N0U3RSBDb25maWd1cmF0aW9uPiBvbiBoaWRidXMwCk1hciAxNiAy MTo0MzoyMSBmcmVlYnNkIGtlcm5lbDogaG10MDogTXVsdGl0b3VjaCB0b3VjaHBhZCB3aXRoIDAg ZXh0ZXJuYWwgYnV0dG9ucywgY2xpY2stcGFkCk1hciAxNiAyMTo0MzoyMSBmcmVlYnNkIGtlcm5l bDogaG10MDogNSBjb250YWN0cyB3aXRoIFtDXSBwcm9wZXJ0aWVzLiBSZXBvcnQgcmFuZ2UgWzA6 MF0gLSBbMTIyOTo3NDldCk1hciAxNiAyMTo0MzoyMSBmcmVlYnNkIGtlcm5lbDogd2xhbjA6IGxp bmsgc3RhdGUgY2hhbmdlZCB0byBVUApNYXIgMTYgMjE6NDM6MjEgZnJlZWJzZCBrZXJuZWw6IHVn ZW4wLjM6IDx2ZW5kb3IgMHg4MDg3IHByb2R1Y3QgMHgwYTJhPiBhdCB1c2J1czAKCi0tLQoKUHVi bGljIEtleTogMjJCRTM5RTJGQTY4RDhCQThEQzRCNDNBNTVBMTZEOENFMkIwMzZERQoKTWVzc2Fn ZXMgZnJvbSB0aGlzIGFjY291bnQgYXJlIGNvbnNpZGVyZWQgdGhlIGJlc3Qtc2VjdXJlZCBhbmQg bW9zdCByZWxpYWJsZS4gU2VuZCBpbmZvcm1hdGlvbiByZWdhcmRpbmcgaGVhbHRoLCB3ZWFsdGgs IG9yIHJlcXVpcmluZyBoaWdoZXIgc3RhbmRhcmRzIG9mIHNlY3VyaXR5IHRvIHRoaXMgYWRkcmVz cy4KClNlbnQgd2l0aCBbUHJvdG9uIE1haWxdKGh0dHBzOi8vcHJvdG9uLm1lL21haWwvaG9tZSkg c2VjdXJlIGVtYWlsLgoKT24gU2F0dXJkYXksIE1hcmNoIDI5dGgsIDIwMjUgYXQgODo0NiBQTSwg U3RldmVuIEhhcm1zIChIaWdoLVNlY3VyaXR5IE1haWwpIDxzZ2hhcm1zQHN0ZXZlbmdoYXJtcy5j b20+IHdyb3RlOgoKPiBIZXkgZm9sa3MsCj4KPiBJIHRyaWVkIGJ1aWxkaW5nIGN1cnJlbnQgZnJv bSBzb3VyY2UgYW5kIHdoZW4gSSBib290LCBJIGdldCBhIHBhbmljIGFmdGVyIHRoZSBmaW5hbCBB dXRvbG9hZGluZyBtb2R1bGUgKHBjaHRoZXJtLCBpbiBteSBjYXNlKSBsb2Fkcy4gQ29tcGFyaW5n IHRvIHRoZSBzdGFibGUgMTQuMiBrZXJuZWwsIHRoZSBuZXh0IHN0ZXAgaXMgZm9yICJTZXR0aW5n IHVwIGhhcnZlc3RpbmcsIiAiRmVlZGluZyBlbnRyb3B5LCIgYW5kIHN0YXJ0aW5nIHdwYV9zdXBw bGljYW50Lgo+Cj4gVG8gYmUgY2xlYXIsIHRoaXMgY29tbWl0IGlzIG5vdCB0aGUgdGhpbmcgdGhh dCBicm9rZSB0aGluZ3MuCj4KPiBJbiBwdXJzdWl0IG9mIGdldHRpbmcgbW9yZSBkYXRhLCBJJ20g dHJ5aW5nIHRvIGlzb2xhdGUgdHdvIHF1ZXN0aW9uczoKPgo+IC0gV2h5IGFtIEkgbm90IGdldHRp bmcgYW55IHBhbmljIGR1bXAgYXJ0aWZhY3RzPwo+IC0gRGlkIEkgYnVpbHQgY3VycmVudCBmcm9t IEhFQUQgcHJvcGVybHk/Cj4KPiBJbiBlZmZvcnQgdG8gZ2V0IG1vcmUgZGF0YSwgSSdtIGZvbGxv d2luZzogaHR0cHM6Ly9kb2NzLmZyZWVic2Qub3JnL2VuL2Jvb2tzL2RldmVsb3BlcnMtaGFuZGJv b2sva2VybmVsZGVidWcvCj4KPiAtIENvbmZpcm0gdGhhdCAvZXRjL3JjLmNvbmYgaGFzIGR1bXBk ZXYgc2V0IHRvIEFVVE8KPiAtIEJvdGggL2V0Yy9mc3RhYiBhbmQgc3dhcCBpbmZvIGNvbmZpcm0g dGhhdCAvZGV2L2FkYTBwMyBpcyBjb25maWd1cmVkIGZvciBzd2FwLiBJdCBpcyBhbHNvIHRoZSBv bmx5IGRldmljZS4gVGhlcmVmb3JlIEkgZXhwZWN0IGR1bXBlZCB0byB3cml0ZSB0byB0aGF0IGRl dmljZQo+IC0gWWV0IGRlc3BpdGUgdGhlIGtlcm5lbCBwYW5pY2tpbmcsIHRoZXJlJ3Mgbm90aGlu ZyBpbiB0aGF0IGRpcmVjdG9yeSBleGNlcHQgZmlsZSAibWluZnJlZSIgd2hpY2ggc2F5cyAiMjA0 OCIgaW4gaXQuCj4gLSBJIG1hbnVhbGx5IHNldCBkdW1wZGlyIHRvICIvdmFyL2NyYXNoIiB3aGlj aCBoYXMgNzUwIHBlcm1pc3Npb25zIGFuZCB0cnkgdG8gYm9vdCB0aGUgbmV3IGtlcm5lbDsgcGFu aWM7IGJvb3QgaW50byBzdGFibGUga2VybmVsIGFuZC4uLm5vdGhpbmcgaW4gL3Zhci9jcmFzaCBl eGNlcHQgbWluZnJlZeKAiwo+Cj4gTm93LCBJJ20gc3RpbGwgdmVyeSBuZXcgdG8gYnVpbGRpbmcg Q1VSUkVOVCwgYnV0IEkndmUgYmVlbiBmb2xsb3dpbmc6Cj4KPiBodHRwczovL2RvY3MuZnJlZWJz ZC5vcmcvZW4vYm9va3MvaGFuZGJvb2svY3V0dGluZy1lZGdlLyN1cGRhdGluZy1zcmMtcXVpY2st c3RhcnQKPgo+ICMgZXRjdXBkYXRlIGV4dHJhY3QgKDEpCj4gIyBldGN1cGRhdGUgZGlmZiAoMikK PiAjIGdpdCBwdWxsIC1DIC91c3Ivc3JjICgxKQo+IGNoZWNrIC91c3Ivc3JjL1VQREFUSU5HICgy KQo+ICMgY2QgL3Vzci9zcmMgKDMpCj4gIyBtYWtlIC1qNCBidWlsZHdvcmxkICg0KQo+ICMgbWFr ZSAtajQga2VybmVsICg1KSMgc2h1dGRvd24gLXIgbm93ICg2KQo+Cj4gQW5kIGFtIGFmdGVyIHRo ZSBzaHV0ZG93biAtciBub3figIsgc3RlcDoKPgo+IElmIG15IHByb2Nlc3MgZm9yIGtlcm5lbCBh bmQgd29ybGQgYnVpbGQgaXMgY29ycmVjdCwgdGhlbiBJIGhhdmUgZm91bmQgYSBwYW5pYy4gSG93 IGNhbiBJIGhlbHAvZGVidWc/Cj4KPiBUaGFua3MhCj4KPiBTdGV2ZW4KPgo+IC0tLQo+Cj4gUHVi bGljIEtleTogMjJCRTM5RTJGQTY4RDhCQThEQzRCNDNBNTVBMTZEOENFMkIwMzZERQo+Cj4gTWVz c2FnZXMgZnJvbSB0aGlzIGFjY291bnQgYXJlIGNvbnNpZGVyZWQgdGhlIGJlc3Qtc2VjdXJlZCBh bmQgbW9zdCByZWxpYWJsZS4gU2VuZCBpbmZvcm1hdGlvbiByZWdhcmRpbmcgaGVhbHRoLCB3ZWFs dGgsIG9yIHJlcXVpcmluZyBoaWdoZXIgc3RhbmRhcmRzIG9mIHNlY3VyaXR5IHRvIHRoaXMgYWRk cmVzcy4KPgo+IFNlbnQgd2l0aCBbUHJvdG9uIE1haWxdKGh0dHBzOi8vcHJvdG9uLm1lL21haWwv aG9tZSkgc2VjdXJlIGVtYWlsLg== --b1=_WUWKov9a0PDExS23HEkfpvymFw96XSXd8sybMuTCl4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0 cHg7Ij5XaXRoIHNvbWUgYWRkaXRpb25hbCBpbnNpZ2h0cyBJIGNhbiBhZGQ6PGJyPjxicj48L2Rp dj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTog MTRweDsiPjxvbCBkYXRhLWVkaXRpbmctaW5mbz0ieyZxdW90O29yZGVyZWRTdHlsZVR5cGUmcXVv dDs6MSwmcXVvdDt1bm9yZGVyZWRTdHlsZVR5cGUmcXVvdDs6MX0iIHN0eWxlPSJtYXJnaW4tdG9w OiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsiIGRhdGEtbGlzdGNoYWluPSJfX0xpc3RfQ2hhaW5f MjI1Ij48bGkgc3R5bGU9Imxpc3Qtc3R5bGUtdHlwZTogJnF1b3Q7MS4gJnF1b3Q7OyI+PHNwYW4+ SSBjYW4gYm9vdCBpbiBzaW5nbGUgdXNlciBvbiAxNS4wLUNVUlJFTlQgKFRoYW5rcyBEYXZlIEMu IGZvciB0aGUgaWRlYSkuIFdlJ3JlIGRlZmluaXRlbHkgZ2V0dGluZyB0byBydW5uaW5nIHRoZSBy YydzIGFuZCBpdCdzIHNvbWV0aGluZyB0aGF0IGJyZWFrcyBhYm91dCB0aGUgdGltZSAvZXRjL3Jj LmQvZGV2bWF0Y2ggc3RhcnRzPC9zcGFuPjwvbGk+PG9sIHN0eWxlPSJtYXJnaW4tdG9wOiAwcHg7 IG1hcmdpbi1ib3R0b206IDBweDsgbGlzdC1zdHlsZS10eXBlOiBsb3dlci1hbHBoYTsiPjxsaSBz dHlsZT0iIj48c3Bhbj5BdCBwcmVzZW50IHRoZXJlIGFyZSBubyBtb2R1bGUgbG9hZHMgaW4gL2V0 Yy9yYy5jb25mOiBrbGRfbGlzdCBpcyBjb21tZW50ZWQtb3V0PC9zcGFuPjwvbGk+PGxpIHN0eWxl PSIiPjxzcGFuPkl0IDxpPnNlZW1zPC9pPiBsaWtlIHRoZSBjdXQgb2ZmIGlzIHdoZW4gdGhlIGtl cm5lbCBzdGFydHMgd29ya2luZyB3aXRoIHRoZSAnaG1zJyBzdWJzeXN0ZW0gKHNlZSBiZWxvdyk8 L3NwYW4+PC9saT48L29sPjwvb2w+PGRpdj48c3Bhbj5JIHdhcyBhYmxlIHRvIGdldCB0aGUgcGFu aWMgb3V0cHV0IGZyb20gbWVzc2FnZXMgLS0gYnV0IHRoZXJlJ3Mgbm8gImhlcmUncyB3aGVyZSB3 ZSBmYWlsZWQsIiBBRkFJQ1QuIEhhdmUgSSBnb3R0ZW4gYWxsIHRoZSB1c2VmdWwgZGVidWdnaW5n IG1lc3NhZ2VzIGF0IHRoaXMgcG9pbnQ/PGJyPjxicj48L3NwYW4+PGRpdj48c3Bhbj5UaGFua3Mg Zm9yIGhlbHAuIEhvcGVmdWxseSB1c2VmdWwgbG9nIGRhdGEgYXJlIGJlbG93Ljwvc3Bhbj48L2Rp dj48ZGl2PjxzcGFuPjxicj48L3NwYW4+PC9kaXY+PGRpdj48c3Bhbj5TdGV2ZW48L3NwYW4+PC9k aXY+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj49PT0gUEFOSUMgPT09PGJyPjxicj48c3Bhbj5B cHIgJm5ic3A7MiAwNDoxNjoyNyBmcmVlYnNkIGtlcm5lbDogaWljaGlkMDogJmx0O0RFTEwwNzNC OjAwIDA2Q0I6N0U3RSBJMkMgSElEIGRldmljZSZndDsgYXQgYWRkciAweDJjIGlycSA1MSBvbiBp aWNidXMwPC9zcGFuPjxkaXY+PHNwYW4+QXByICZuYnNwOzIgMDQ6MTY6MjcgZnJlZWJzZCBrZXJu ZWw6IGhpZGJ1czA6ICZsdDtISUQgYnVzJmd0OyBvbiBpaWNoaWQwPC9zcGFuPjwvZGl2PjxkaXY+ PHNwYW4+QXByICZuYnNwOzIgMDQ6MTY6MjcgZnJlZWJzZCBrZXJuZWw6IDwvc3Bhbj48L2Rpdj48 ZGl2PjxzcGFuPkFwciAmbmJzcDsyIDA0OjE2OjI3IGZyZWVic2Qgc3lzbG9nZDogbGFzdCBtZXNz YWdlIHJlcGVhdGVkIDEgdGltZXM8L3NwYW4+PC9kaXY+PGRpdj48c3Bhbj5BcHIgJm5ic3A7MiAw NDoxNjoyNyBmcmVlYnNkIGtlcm5lbDogRmF0YWwgdHJhcCAxMjogcGFnZSBmYXVsdCB3aGlsZSBp biBrZXJuZWwgbW9kZTwvc3Bhbj48L2Rpdj48ZGl2PjxzcGFuPkFwciAmbmJzcDsyIDA0OjE2OjI3 IGZyZWVic2Qga2VybmVsOiBjcHVpZCA9IDA7IGFwaWMgaWQgPSAwMDwvc3Bhbj48L2Rpdj48ZGl2 PjxzcGFuPkFwciAmbmJzcDsyIDA0OjE2OjI3IGZyZWVic2Qga2VybmVsOiBmYXVsdCB2aXJ0dWFs IGFkZHJlc3MJPSAweDA8L3NwYW4+PC9kaXY+PGRpdj48c3Bhbj5BcHIgJm5ic3A7MiAwNDoxNjoy NyBmcmVlYnNkIGtlcm5lbDogZmF1bHQgY29kZQkJPSBzdXBlcnZpc29yIHJlYWQgaW5zdHJ1Y3Rp b24sIHBhZ2Ugbm90IHByZXNlbnQ8L3NwYW4+PC9kaXY+PGRpdj48c3Bhbj5BcHIgJm5ic3A7MiAw NDoxNjoyNyBmcmVlYnNkIGtlcm5lbDogaW5zdHJ1Y3Rpb24gcG9pbnRlcgk9IDB4MjA6MHgwPC9z cGFuPjwvZGl2PjxkaXY+PHNwYW4+QXByICZuYnNwOzIgMDQ6MTY6MjcgZnJlZWJzZCBrZXJuZWw6 IHN0YWNrIHBvaW50ZXIJICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOz0gMHgyODoweGZmZmZm ZTAwNjhkZmNlMzg8L3NwYW4+PC9kaXY+PGRpdj48c3Bhbj5BcHIgJm5ic3A7MiAwNDoxNjoyNyBm cmVlYnNkIGtlcm5lbDogZnJhbWUgcG9pbnRlcgkgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 PSAweDI4OjB4ZmZmZmZlMDA2OGRmY2U2MDwvc3Bhbj48L2Rpdj48ZGl2PjxzcGFuPkFwciAmbmJz cDsyIDA0OjE2OjI3IGZyZWVic2Qga2VybmVsOiBjb2RlIHNlZ21lbnQJCT0gYmFzZSAweDAsIGxp bWl0IDB4ZmZmZmYsIHR5cGUgMHgxYjwvc3Bhbj48L2Rpdj48ZGl2PjxzcGFuPkFwciAmbmJzcDsy IDA0OjE2OjI3IGZyZWVic2Qga2VybmVsOiAJCQk9IERQTCAwLCBwcmVzIDEsIGxvbmcgMSwgZGVm MzIgMCwgZ3JhbiAxPC9zcGFuPjwvZGl2PjxkaXY+PHNwYW4+QXByICZuYnNwOzIgMDQ6MTY6Mjcg ZnJlZWJzZCBrZXJuZWw6IHByb2Nlc3NvciBlZmxhZ3MJPSBpbnRlcnJ1cHQgZW5hYmxlZCwgcmVz dW1lLCBJT1BMID0gMDwvc3Bhbj48L2Rpdj48c3Bhbj48L3NwYW4+PC9kaXY+PGRpdj48YnI+PC9k aXY+PGRpdj48b2wgZGF0YS1lZGl0aW5nLWluZm89InsmcXVvdDtvcmRlcmVkU3R5bGVUeXBlJnF1 b3Q7OjEsJnF1b3Q7dW5vcmRlcmVkU3R5bGVUeXBlJnF1b3Q7OjF9IiBzdHlsZT0ibWFyZ2luLXRv cDogMHB4OyBtYXJnaW4tYm90dG9tOiAwcHg7IiBkYXRhLWxpc3RjaGFpbj0iX19MaXN0X0NoYWlu XzIyNiI+PGxpIHN0eWxlPSJsaXN0LXN0eWxlLXR5cGU6ICZxdW90OzEuICZxdW90OzsiPjxzcGFu PkknbSBzdXJwcmlzZWQgYnkgdGhlICJibGFuayBsaWtlIiByZXBlYXRlZCAxIHRpbWVzPC9zcGFu PjwvbGk+PGxpIHN0eWxlPSJsaXN0LXN0eWxlLXR5cGU6ICZxdW90OzIuICZxdW90OzsiPjxzcGFu PlRoaXMgcG9ydGlvbiBvZiB0aGUgdHJhY2UgZGlkbid0IHJlYWxseSBoZWxwIG1lLCBidXQgdGhl c2UgY2FsbCBzdGFja3Mgc2VlbWVkIGludGVyZXN0aW5nIHRvbzwvc3Bhbj48L2xpPjwvb2w+PGRp dj48YnI+PC9kaXY+PGRpdj48c3Bhbj5JbnRlcmVzdGluZyBzdGFjayBkYXRhPzwvc3Bhbj48ZGl2 Pjxicj48L2Rpdj48ZGl2PjxzcGFuPkFwciAmbmJzcDsyIDA0OjE2OjI3IGZyZWVic2Qga2VybmVs OiBLREI6IHN0YWNrIGJhY2t0cmFjZTo8L3NwYW4+PGRpdj48c3Bhbj5BcHIgJm5ic3A7MiAwNDox NjoyNyBmcmVlYnNkIGtlcm5lbDogZGJfdHJhY2Vfc2VsZl93cmFwcGVyKCkgYXQgZGJfdHJhY2Vf c2VsZl93cmFwcGVyKzB4MmIvZnJhbWUgMHhmZmZmZmUwMDY4ZGZjYjYwPC9zcGFuPjwvZGl2Pjxk aXY+PHNwYW4+QXByICZuYnNwOzIgMDQ6MTY6MjcgZnJlZWJzZCBrZXJuZWw6IHZwYW5pYygpIGF0 IHZwYW5pYysweDEzNi9mcmFtZSAweGZmZmZmZTAwNjhkZmNjOTA8L3NwYW4+PC9kaXY+PGRpdj48 c3Bhbj5BcHIgJm5ic3A7MiAwNDoxNjoyNyBmcmVlYnNkIGtlcm5lbDogcGFuaWMoKSBhdCBwYW5p YysweDQzL2ZyYW1lIDB4ZmZmZmZlMDA2OGRmY2NmMDwvc3Bhbj48L2Rpdj48ZGl2PjxzcGFuPkFw ciAmbmJzcDsyIDA0OjE2OjI3IGZyZWVic2Qga2VybmVsOiB0cmFwX3BmYXVsdCgpIGF0IHRyYXBf cGZhdWx0KzB4NDY2L2ZyYW1lIDB4ZmZmZmZlMDA2OGRmY2Q2MDwvc3Bhbj48L2Rpdj48ZGl2Pjxz cGFuPkFwciAmbmJzcDsyIDA0OjE2OjI3IGZyZWVic2Qga2VybmVsOiBjYWxsdHJhcCgpIGF0IGNh bGx0cmFwKzB4OC9mcmFtZSAweGZmZmZmZTAwNjhkZmNkNjA8L3NwYW4+PC9kaXY+PGRpdj48c3Bh bj5BcHIgJm5ic3A7MiAwNDoxNjoyNyBmcmVlYnNkIGtlcm5lbDogLS0tIHRyYXAgMHhjLCByaXAg PSAwLCByc3AgPSAweGZmZmZmZTAwNjhkZmNlMzgsIHJicCA9IDB4ZmZmZmZlMDA2OGRmY2U2MCAt LS08L3NwYW4+PC9kaXY+PGRpdj48c3Bhbj5BcHIgJm5ic3A7MiAwNDoxNjoyNyBmcmVlYnNkIGtl cm5lbDogPz8oKSBhdCAwL2ZyYW1lIDB4ZmZmZmZlMDA2OGRmY2U2MDwvc3Bhbj48L2Rpdj48ZGl2 PjxzcGFuPkFwciAmbmJzcDsyIDA0OjE2OjI3IGZyZWVic2Qga2VybmVsOiBpdGhyZWFkX2xvb3Ao KSBhdCBpdGhyZWFkX2xvb3ArMHgyNjYvZnJhbWUgMHhmZmZmZmUwMDY4ZGZjZWYwPC9zcGFuPjwv ZGl2PjxkaXY+PHNwYW4+QXByICZuYnNwOzIgMDQ6MTY6MjcgZnJlZWJzZCBrZXJuZWw6IGZvcmtf ZXhpdCgpIGF0IGZvcmtfZXhpdCsweDgyL2ZyYW1lIDB4ZmZmZmZlMDA2OGRmY2YzMDwvc3Bhbj48 L2Rpdj48ZGl2PjxzcGFuPkFwciAmbmJzcDsyIDA0OjE2OjI3IGZyZWVic2Qga2VybmVsOiBmb3Jr X3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUrMHhlL2ZyYW1lIDB4ZmZmZmZlMDA2OGRm Y2YzMDwvc3Bhbj48L2Rpdj48ZGl2PjxzcGFuPkFwciAmbmJzcDsyIDA0OjE2OjI3IGZyZWVic2Qg a2VybmVsOiAtLS0gdHJhcCAwLCByaXAgPSAwLCByc3AgPSAweDEsIHJicCA9IDB4MzUwMTNmYzVl YTQ0IC0tLTwvc3Bhbj48L2Rpdj48c3Bhbj48c3Bhbj5BcHIgJm5ic3A7MiAwNDoxNjoyNyBmcmVl YnNkIGtlcm5lbDogS0RCOiBlbnRlcjogcGFuaWM8L3NwYW4+PC9zcGFuPjxzcGFuPjwvc3Bhbj48 L2Rpdj48YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj49PT09IFVzaW5nIG15IG9sZCwgc3Rh YmxlIGtlcm5lbDo9PT08L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PkhlcmUncyB3aGF0IGNvbWVz IG5leHQ6PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48c3Bhbj5NYXIgMTYgMjE6NDM6MjEgZnJl ZWJzZCBrZXJuZWw6IGlpY2hpZDA6ICZsdDtERUxMMDczQjowMCAwNkNCOjdFN0UgSTJDIEhJRCBk ZXZpY2UmZ3Q7IGF0IGFkZHIgMHgyYyBpcnEgNTEgb24gaWljYnVzMDwvc3Bhbj48ZGl2PjxzcGFu Pk1hciAxNiAyMTo0MzoyMSBmcmVlYnNkIGtlcm5lbDogaGlkYnVzMDogJmx0O0hJRCBidXMmZ3Q7 IG9uIGlpY2hpZDA8L3NwYW4+PC9kaXY+PGRpdj48c3Bhbj5NYXIgMTYgMjE6NDM6MjEgZnJlZWJz ZCBrZXJuZWw6IGhtczA6ICZsdDtERUxMMDczQjowMCAwNkNCOjdFN0UgTW91c2UmZ3Q7IG9uIGhp ZGJ1czA8L3NwYW4+PC9kaXY+PGRpdj48c3Bhbj5NYXIgMTYgMjE6NDM6MjEgZnJlZWJzZCBrZXJu ZWw6IGhtczA6IDIgYnV0dG9ucyBhbmQgW1hZXSBjb29yZGluYXRlcyBJRD0yPC9zcGFuPjwvZGl2 PjxkaXY+PHNwYW4+TWFyIDE2IDIxOjQzOjIxIGZyZWVic2Qga2VybmVsOiBobXQwOiAmbHQ7REVM TDA3M0I6MDAgMDZDQjo3RTdFIFRvdWNoUGFkJmd0OyBvbiBoaWRidXMwPC9zcGFuPjwvZGl2Pjxk aXY+PHNwYW4+TWFyIDE2IDIxOjQzOjIxIGZyZWVic2Qga2VybmVsOiBoY29uZjA6ICZsdDtERUxM MDczQjowMCAwNkNCOjdFN0UgQ29uZmlndXJhdGlvbiZndDsgb24gaGlkYnVzMDwvc3Bhbj48L2Rp dj48ZGl2PjxzcGFuPk1hciAxNiAyMTo0MzoyMSBmcmVlYnNkIGtlcm5lbDogaG10MDogTXVsdGl0 b3VjaCB0b3VjaHBhZCB3aXRoIDAgZXh0ZXJuYWwgYnV0dG9ucywgY2xpY2stcGFkPC9zcGFuPjwv ZGl2PjxkaXY+PHNwYW4+TWFyIDE2IDIxOjQzOjIxIGZyZWVic2Qga2VybmVsOiBobXQwOiA1IGNv bnRhY3RzIHdpdGggW0NdIHByb3BlcnRpZXMuIFJlcG9ydCByYW5nZSBbMDowXSAtIFsxMjI5Ojc0 OV08L3NwYW4+PC9kaXY+PGRpdj48c3Bhbj5NYXIgMTYgMjE6NDM6MjEgZnJlZWJzZCBrZXJuZWw6 IHdsYW4wOiBsaW5rIHN0YXRlIGNoYW5nZWQgdG8gVVA8L3NwYW4+PC9kaXY+PGRpdj48c3Bhbj5N YXIgMTYgMjE6NDM6MjEgZnJlZWJzZCBrZXJuZWw6IHVnZW4wLjM6ICZsdDt2ZW5kb3IgMHg4MDg3 IHByb2R1Y3QgMHgwYTJhJmd0OyBhdCB1c2J1czA8L3NwYW4+PC9kaXY+PHNwYW4+PC9zcGFuPjxi cj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48L2Rpdj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWls eTogQXJpYWwsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPjxicj48L2Rpdj4NCjxkaXYg Y2xhc3M9InByb3Rvbm1haWxfc2lnbmF0dXJlX2Jsb2NrIiBzdHlsZT0iZm9udC1mYW1pbHk6IEFy aWFsLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCiAgICA8ZGl2IGNsYXNzPSJwcm90 b25tYWlsX3NpZ25hdHVyZV9ibG9jay11c2VyIj4NCiAgICAgICAgPGRpdj4tLS08YnI+PC9kaXY+ PGRpdj48YnI+PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlm OyBmb250LXNpemU6IDE0cHg7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGJhY2tncm91bmQtY29sb3I6 IHJnYigyNTUsIDI1NSwgMjU1KTsiPlB1YmxpYyBLZXk6IDxhIHRpdGxlPSIyMkJFMzlFMkZBNjhE OEJBOERDNEI0M0E1NUExNkQ4Q0UyQjAzNkRFIiBocmVmPSJodHRwczovLzIyQkUzOUUyRkE2OEQ4 QkE4REM0QjQzQTU1QTE2RDhDRTJCMDM2REUiPjxzcGFuPjIyQkUzOUUyRkE2OEQ4QkE4REM0QjQz QTU1QTE2RDhDRTJCMDM2REU8L3NwYW4+PC9hPjxicj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LXN0 eWxlOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7 IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9y bWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyBmb250LWZhbWls eTogQXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzNCwgMzQsIDM0KTsi Pjxicj48L2Rpdj48ZGl2Pk1lc3NhZ2VzIGZyb20gdGhpcyBhY2NvdW50IGFyZSBjb25zaWRlcmVk IHRoZSBiZXN0LXNlY3VyZWQgYW5kIG1vc3QgcmVsaWFibGUuIFNlbmQgaW5mb3JtYXRpb24gcmVn YXJkaW5nIGhlYWx0aCwgd2VhbHRoLCBvciByZXF1aXJpbmcgaGlnaGVyIHN0YW5kYXJkcyBvZiBz ZWN1cml0eSB0byB0aGlzIGFkZHJlc3MuPGJyPjwvZGl2Pg0KICAgIDwvZGl2Pg0KICAgIDxkaXYg c3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+ PGJyPjwvZGl2Pg0KICAgIDxkaXYgY2xhc3M9InByb3Rvbm1haWxfc2lnbmF0dXJlX2Jsb2NrLXBy b3RvbiI+DQogICAgICAgIFNlbnQgd2l0aCA8YSB0YXJnZXQ9Il9ibGFuayIgaHJlZj0iaHR0cHM6 Ly9wcm90b24ubWUvbWFpbC9ob21lIj5Qcm90b24gTWFpbDwvYT4gc2VjdXJlIGVtYWlsLg0KICAg IDwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2Vy aWY7IGZvbnQtc2l6ZTogMTRweDsiPjxicj48L2Rpdj48ZGl2IGNsYXNzPSJwcm90b25tYWlsX3F1 b3RlIj4NCiAgICAgICAgT24gU2F0dXJkYXksIE1hcmNoIDI5dGgsIDIwMjUgYXQgODo0NiBQTSwg U3RldmVuIEhhcm1zIChIaWdoLVNlY3VyaXR5IE1haWwpICZsdDtzZ2hhcm1zQHN0ZXZlbmdoYXJt cy5jb20mZ3Q7IHdyb3RlOjxicj4NCiAgICAgICAgPGJsb2NrcXVvdGUgY2xhc3M9InByb3Rvbm1h aWxfcXVvdGUiIHR5cGU9ImNpdGUiPg0KICAgICAgICAgICAgPGRpdiBzdHlsZT0iZm9udC1mYW1p bHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij5IZXkgZm9sa3MsPC9kaXY+ PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0 cHg7Ij48YnI+PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlm OyBmb250LXNpemU6IDE0cHg7Ij5JIHRyaWVkIGJ1aWxkaW5nIGN1cnJlbnQgZnJvbSBzb3VyY2Ug YW5kIHdoZW4gSSBib290LCBJIGdldCBhIHBhbmljIGFmdGVyIHRoZSBmaW5hbCBBdXRvbG9hZGlu ZyBtb2R1bGUgKHBjaHRoZXJtLCBpbiBteSBjYXNlKSBsb2Fkcy4gQ29tcGFyaW5nIHRvIHRoZSBz dGFibGUgMTQuMiBrZXJuZWwsIHRoZSBuZXh0IHN0ZXAgaXMgZm9yICJTZXR0aW5nIHVwIGhhcnZl c3RpbmcsIiAiRmVlZGluZyBlbnRyb3B5LCIgYW5kIHN0YXJ0aW5nIHdwYV9zdXBwbGljYW50Ljwv ZGl2PjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsgZm9udC1zaXpl OiAxNHB4OyI+PGJyPjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1z ZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+VG8gYmUgY2xlYXIsIHRoaXMgY29tbWl0IGlzIG5vdCB0 aGUgdGhpbmcgdGhhdCBicm9rZSB0aGluZ3MuPC9kaXY+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6 IEFyaWFsLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij48YnI+PC9kaXY+PGRpdiBzdHls ZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij5JbiBw dXJzdWl0IG9mIGdldHRpbmcgbW9yZSBkYXRhLCBJJ20gdHJ5aW5nIHRvIGlzb2xhdGUgdHdvIHF1 ZXN0aW9uczo8L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7 IGZvbnQtc2l6ZTogMTRweDsiPjxicj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQXJp YWwsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPjxvbCBkYXRhLWxpc3RjaGFpbj0iX19M aXN0X0NoYWluXzIyMSIgc3R5bGU9Im1hcmdpbi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4 OyIgZGF0YS1lZGl0aW5nLWluZm89InsmcXVvdDtvcmRlcmVkU3R5bGVUeXBlJnF1b3Q7OjEsJnF1 b3Q7dW5vcmRlcmVkU3R5bGVUeXBlJnF1b3Q7OjF9Ij48bGkgc3R5bGU9Imxpc3Qtc3R5bGUtdHlw ZTogJnF1b3Q7MS4gJnF1b3Q7OyI+V2h5IGFtIEkgbm90IGdldHRpbmcgYW55IHBhbmljIGR1bXAg YXJ0aWZhY3RzPzwvbGk+PGxpIHN0eWxlPSJsaXN0LXN0eWxlLXR5cGU6ICZxdW90OzIuICZxdW90 OzsiPkRpZCBJIGJ1aWx0IGN1cnJlbnQgZnJvbSBIRUFEIHByb3Blcmx5PzwvbGk+PC9vbD48L2Rp dj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTog MTRweDsiPjxicj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2Vy aWY7IGZvbnQtc2l6ZTogMTRweDsiPkluIGVmZm9ydCB0byBnZXQgbW9yZSBkYXRhLCBJJ20gZm9s bG93aW5nOiZuYnNwOzxzcGFuPjxhIGhyZWY9Imh0dHBzOi8vZG9jcy5mcmVlYnNkLm9yZy9lbi9i b29rcy9kZXZlbG9wZXJzLWhhbmRib29rL2tlcm5lbGRlYnVnLyIgcmVsPSJub3JlZmVycmVyIG5v Zm9sbG93IG5vb3BlbmVyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kb2NzLmZyZWVic2Qub3Jn L2VuL2Jvb2tzL2RldmVsb3BlcnMtaGFuZGJvb2sva2VybmVsZGVidWcvPC9hPjwvc3Bhbj48L2Rp dj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTog MTRweDsiPjxicj48L2Rpdj48ZGl2PjxvbCBkYXRhLWxpc3RjaGFpbj0iX19MaXN0X0NoYWluXzIy MiIgc3R5bGU9Im1hcmdpbi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyIgZGF0YS1lZGl0 aW5nLWluZm89InsmcXVvdDtvcmRlcmVkU3R5bGVUeXBlJnF1b3Q7OjEsJnF1b3Q7dW5vcmRlcmVk U3R5bGVUeXBlJnF1b3Q7OjF9Ij48bGkgc3R5bGU9Imxpc3Qtc3R5bGUtdHlwZTogJnF1b3Q7MS4g JnF1b3Q7OyI+PGZvbnQgZmFjZT0iQXJpYWwsIHNhbnMtc2VyaWYiPkNvbmZpcm0gdGhhdCAvZXRj L3JjLmNvbmYgaGFzIGR1bXBkZXYgc2V0IHRvIEFVVE88L2ZvbnQ+PC9saT48bGkgc3R5bGU9Imxp c3Qtc3R5bGUtdHlwZTogJnF1b3Q7Mi4gJnF1b3Q7OyI+PGZvbnQgZmFjZT0iQXJpYWwsIHNhbnMt c2VyaWYiPkJvdGggL2V0Yy9mc3RhYiBhbmQgc3dhcCBpbmZvIGNvbmZpcm0gdGhhdCAvZGV2L2Fk YTBwMyBpcyBjb25maWd1cmVkIGZvciBzd2FwLiBJdCBpcyBhbHNvIHRoZSBvbmx5IGRldmljZS4g VGhlcmVmb3JlIEkgZXhwZWN0IGR1bXBlZCB0byB3cml0ZSB0byB0aGF0IGRldmljZTwvZm9udD48 L2xpPjxsaSBzdHlsZT0ibGlzdC1zdHlsZS10eXBlOiAmcXVvdDszLiAmcXVvdDs7Ij48Zm9udCBm YWNlPSJBcmlhbCwgc2Fucy1zZXJpZiI+WWV0IGRlc3BpdGUgdGhlIGtlcm5lbCBwYW5pY2tpbmcs IHRoZXJlJ3Mgbm90aGluZyBpbiB0aGF0IGRpcmVjdG9yeSBleGNlcHQgZmlsZSAibWluZnJlZSIg d2hpY2ggc2F5cyAiMjA0OCIgaW4gaXQuPC9mb250PjwvbGk+PGxpIHN0eWxlPSJsaXN0LXN0eWxl LXR5cGU6ICZxdW90OzQuICZxdW90OzsiPjxmb250IGZhY2U9IkFyaWFsLCBzYW5zLXNlcmlmIj5J IG1hbnVhbGx5IHNldCBkdW1wZGlyIHRvICIvdmFyL2NyYXNoIiB3aGljaCBoYXMgNzUwIHBlcm1p c3Npb25zIGFuZCB0cnkgdG8gYm9vdCB0aGUgbmV3IGtlcm5lbDsgcGFuaWM7IGJvb3QgaW50byBz dGFibGUga2VybmVsIGFuZC4uLm5vdGhpbmcgaW4gL3Zhci9jcmFzaCBleGNlcHQgPGNvZGU+bWlu ZnJlZTwvY29kZT7igIs8L2ZvbnQ+PC9saT48L29sPjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtZmFt aWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+PGJyPjwvZGl2PjxkaXYg c3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+ Tm93LCBJJ20gc3RpbGwgdmVyeSBuZXcgdG8gYnVpbGRpbmcgQ1VSUkVOVCwgYnV0IEkndmUgYmVl biBmb2xsb3dpbmc6PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNl cmlmOyBmb250LXNpemU6IDE0cHg7Ij48YnI+PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6 IEFyaWFsLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij48c3Bhbj48YSBocmVmPSJodHRw czovL2RvY3MuZnJlZWJzZC5vcmcvZW4vYm9va3MvaGFuZGJvb2svY3V0dGluZy1lZGdlLyN1cGRh dGluZy1zcmMtcXVpY2stc3RhcnQiIHJlbD0ibm9yZWZlcnJlciBub2ZvbGxvdyBub29wZW5lciIg dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZG9jcy5mcmVlYnNkLm9yZy9lbi9ib29rcy9oYW5kYm9v ay9jdXR0aW5nLWVkZ2UvI3VwZGF0aW5nLXNyYy1xdWljay1zdGFydDwvYT48L3NwYW4+PGJyPjwv ZGl2PjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsgZm9udC1zaXpl OiAxNHB4OyI+PGJyPjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1z ZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+PHNwYW4+IyBldGN1cGRhdGUgZXh0cmFjdCAoMSk8L3Nw YW4+PGRpdj48c3Bhbj4jIGV0Y3VwZGF0ZSBkaWZmICgyKTwvc3Bhbj48L2Rpdj48ZGl2PjxzcGFu PiMgZ2l0IHB1bGwgLUMgL3Vzci9zcmMgJm5ic3A7KDEpPC9zcGFuPjwvZGl2PjxkaXY+PHNwYW4+ Y2hlY2sgL3Vzci9zcmMvVVBEQVRJTkcgJm5ic3A7KDIpPC9zcGFuPjwvZGl2PjxkaXY+PHNwYW4+ IyBjZCAvdXNyL3NyYyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7KDMpPC9zcGFu PjwvZGl2PjxkaXY+PHNwYW4+IyBtYWtlIC1qNCBidWlsZHdvcmxkICZuYnNwOyg0KTwvc3Bhbj48 L2Rpdj48ZGl2PjxzcGFuPiMgbWFrZSAtajQga2VybmVsICZuYnNwOyAmbmJzcDsgJm5ic3A7KDUp PC9zcGFuPjwvZGl2PjxzcGFuPiMgc2h1dGRvd24gLXIgbm93ICZuYnNwOyAmbmJzcDsgJm5ic3A7 KDYpPC9zcGFuPjxicj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMt c2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPjxicj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWls eTogQXJpYWwsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPkFuZCBhbSBhZnRlciB0aGUg PGNvZGU+c2h1dGRvd24gLXIgbm93PC9jb2RlPuKAiyBzdGVwOjwvZGl2PjxkaXYgc3R5bGU9ImZv bnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+PGJyPjwvZGl2 PjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAx NHB4OyI+SWYgbXkgcHJvY2VzcyBmb3Iga2VybmVsIGFuZCB3b3JsZCBidWlsZCBpcyBjb3JyZWN0 LCB0aGVuIEkgaGF2ZSBmb3VuZCBhIHBhbmljLiBIb3cgY2FuIEkgaGVscC9kZWJ1Zz88L2Rpdj48 ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRw eDsiPjxicj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7 IGZvbnQtc2l6ZTogMTRweDsiPlRoYW5rcyE8L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTog QXJpYWwsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPjxicj48L2Rpdj48ZGl2IHN0eWxl PSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPlN0ZXZl bjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsgZm9udC1z aXplOiAxNHB4OyI+PGJyPjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBz YW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7IiBjbGFzcz0icHJvdG9ubWFpbF9zaWduYXR1cmVf YmxvY2siPg0KICAgIDxkaXYgY2xhc3M9InByb3Rvbm1haWxfc2lnbmF0dXJlX2Jsb2NrLXVzZXIi Pg0KICAgICAgICA8ZGl2Pi0tLTxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2IHN0eWxlPSJm b250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsgY29sb3I6IHJn YigwLCAwLCAwKTsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyI+UHVibGlj IEtleTogPGEgaHJlZj0iaHR0cHM6Ly8yMkJFMzlFMkZBNjhEOEJBOERDNEI0M0E1NUExNkQ4Q0Uy QjAzNkRFIiB0aXRsZT0iMjJCRTM5RTJGQTY4RDhCQThEQzRCNDNBNTVBMTZEOENFMkIwMzZERSIg dGFyZ2V0PSJfYmxhbmsiIHJlbD0ibm9yZWZlcnJlciBub2ZvbGxvdyBub29wZW5lciI+PHNwYW4+ MjJCRTM5RTJGQTY4RDhCQThEQzRCNDNBNTVBMTZEOENFMkIwMzZERTwvc3Bhbj48L2E+PGJyPjwv ZGl2PjxkaXYgc3R5bGU9ImZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsg bGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06 IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyB0ZXh0LWRlY29y YXRpb246IG5vbmU7IGZvbnQtZmFtaWx5OiBBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBj b2xvcjogcmdiKDM0LCAzNCwgMzQpOyI+PGJyPjwvZGl2PjxkaXY+TWVzc2FnZXMgZnJvbSB0aGlz IGFjY291bnQgYXJlIGNvbnNpZGVyZWQgdGhlIGJlc3Qtc2VjdXJlZCBhbmQgbW9zdCByZWxpYWJs ZS4gU2VuZCBpbmZvcm1hdGlvbiByZWdhcmRpbmcgaGVhbHRoLCB3ZWFsdGgsIG9yIHJlcXVpcmlu ZyBoaWdoZXIgc3RhbmRhcmRzIG9mIHNlY3VyaXR5IHRvIHRoaXMgYWRkcmVzcy48YnI+PC9kaXY+ DQogICAgPC9kaXY+DQogICAgPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNl cmlmOyBmb250LXNpemU6IDE0cHg7Ij48YnI+PC9kaXY+DQogICAgPGRpdiBjbGFzcz0icHJvdG9u bWFpbF9zaWduYXR1cmVfYmxvY2stcHJvdG9uIj4NCiAgICAgICAgU2VudCB3aXRoIDxhIGhyZWY9 Imh0dHBzOi8vcHJvdG9uLm1lL21haWwvaG9tZSIgdGFyZ2V0PSJfYmxhbmsiIHJlbD0ibm9yZWZl cnJlciBub2ZvbGxvdyBub29wZW5lciI+UHJvdG9uIE1haWw8L2E+IHNlY3VyZSBlbWFpbC4NCiAg ICA8L2Rpdj4NCjwvZGl2Pg0KDQogICAgICAgIDwvYmxvY2txdW90ZT48YnI+DQogICAgPC9kaXY+ --b1=_WUWKov9a0PDExS23HEkfpvymFw96XSXd8sybMuTCl4-- From nobody Wed Apr 2 20:51: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 4ZScVN3M9Xz5rc1R for ; Wed, 02 Apr 2025 20:51:40 +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 4ZScVM23nyz3c1P for ; Wed, 02 Apr 2025 20:51: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=JcY1D8h8; 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-5e6c18e2c7dso427989a12.3 for ; Wed, 02 Apr 2025 13:51:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1743627096; x=1744231896; darn=freebsd.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=1KBk78EcvEGBaNHpUS6TRrlYVUdqOZ7rsN2A2YzRm+I=; b=JcY1D8h8zkQXKlm7eCy5P73O4NO6xJPvuC+zJN80FqeRBiryIqOCp9s+jbG8aDUjIZ po0IBBhRlGQjKRXH36rQ9QuXKc29BZ4grEK2NRiwK+BLf4avp6ybHS4d66MI9Kf2TxBF gNGAvbXtSu+IIvQznxPtUThsxPPNiD71D0q+Ol4pHStuHfBbmdhEB/LQ4GkqFX8KeMYJ LRlmfzE01ASj9DOuPfIx0nDXhNgLhWX37ZNySIl93R1BnruxZfpe5taw6sykb5EE2/hP kt2jG36gjtU629dYOPTo0iLZRjY611SVwl6lKIBFzPcicSneebosS4VYcIGcYJaNGKze 1B9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743627096; x=1744231896; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=1KBk78EcvEGBaNHpUS6TRrlYVUdqOZ7rsN2A2YzRm+I=; b=A/44jP5K+izzWMuxD6EWJlKCgKQfQ+HzYKCM6MtMojfOhxYJP3gn0vUSSoLrfjyFV3 db0kNuB6vQPhMfdyl1iJVjj0xdkvvz7oi0tnJ8C2HEfHRE27/2f0ALNwwLjKVw0IWewa tmfX5OhRFpLeHiZmcN7oRFx9ZHME0sSV8b/o7Nu86aqzSNOLfo18cEe3bHxK5D3zD44l wndiHrtwCIYYcpzyG51MEUUXaQ5PrQ7vxPl3Z6ttGqFmz4Wmt8lwql9Gfy9EGEh6VR0r pNYMrN5UtGjLsKO4JrK2yLwG4LheRS/D/4kb1GbDZNd7eK6LYttd3mZW5mOaNX8TvYzz S4MQ== X-Gm-Message-State: AOJu0YwNgxhMnsBbVixxTGV5MS22vN4Wvovj74iz8H7CjafBdT6EPC0W x3PF+hT0KKqpbLdl/MDuM1+l0SV9YmMOKORTLAE2x2NIfAi/Men2PRtIlOcDj5j/4P3kAAxDnT0 WvBgUV6BgYVg6E19Qmg6ZwA/C+1gqbGk= X-Gm-Gg: ASbGncupI6v8YeWSbXoT2EREsVq+l9WJFf7q/B73Ckryk73wn6htKcrQ716ymiMFnjo Gt5MbXIs+0x//J+MSFn5XCCGu2vfH/as7W6eCbE/btlhH4l/AX+V0JyDO2Iv14I7pddfYINGmI9 5wQxgWs4vUgEgEY6fpu2jU/vpAM7coLMZZedgNNtM75Rshar1qWC2BfqPf1g== X-Google-Smtp-Source: AGHT+IGbnzVdEOATaqLERe7WP4YNOKfFPf6lLlqWhOR/dJA4hlmZOncjFITadMbAq+myuxQjz3rxR2UC9G5MW69qLzM= X-Received: by 2002:a05:6402:5207:b0:5dc:c943:7b6 with SMTP id 4fb4d7f45d1cf-5f04eaa7020mr4097878a12.3.1743627095999; Wed, 02 Apr 2025 13:51: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 From: Rick Macklem Date: Wed, 2 Apr 2025 13:51:26 -0700 X-Gm-Features: AQ5f1JqW-S8iJ0-UIvodr9F97ElVTTmpYwl0h3E4-7ojrG_OpOtpKvyKvQeg4L4 Message-ID: Subject: Heads Up: commit 2ec2ba7e232d just hit main To: FreeBSD CURRENT Content-Type: text/plain; charset="UTF-8" X-Spamd-Result: default: False [-0.53 / 15.00]; NEURAL_SPAM_LONG(0.98)[0.979]; NEURAL_HAM_MEDIUM(-0.70)[-0.702]; 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]; NEURAL_SPAM_SHORT(0.19)[0.190]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TO_DN_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; TAGGED_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MISSING_XM_UA(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::536:from] X-Rspamd-Queue-Id: 4ZScVM23nyz3c1P X-Spamd-Bar: / The commit 2ec2ba7e232d just hit main. I do not think it will cause problems, but it is fairly large. Man page updates will be done as separate commits. Hopefully this will not cause grief, rick From nobody Wed Apr 2 21:26: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 4ZSdGK5fChz5rtnv for ; Wed, 02 Apr 2025 21:26:17 +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 4ZSdGK0RZmz3kVx for ; Wed, 02 Apr 2025 21:26:17 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=DH1AGXiH; 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-5e5e63162a0so367569a12.3 for ; Wed, 02 Apr 2025 14:26:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1743629174; x=1744233974; 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=AsgpuCeamfuItSE2ZQUt1xIIqI9RqAD/ZBJYfDWlNSI=; b=DH1AGXiH3GYUWq2MmiNTRUQyk61NcU/u3sc9YDeYxow3K+MWAuWbfwJUrufXSefAst qj1SkVA2e2QpXk992U9DujM1qYnXAJvKe3qyNwGpGXrgpBYYB//LBxW5Q+QUDMhYyH1J JN69LMajZaExRbrnLsrkXsar2lkO+4VeVJB/tHYkrKVj+MQcVNRX4AtkKuoTsSHYeZ+i WRFbQQhpHA6/hPUKRKtvbdLtjltC+OnmnigSxL3HH4a3jZqacRxygXuicKq+Hn3eN1L6 rYVdtBUNqmzF5zjckpI23T9RmgVJM1fOktp9vBL0TrfQEtGmAV/0O0vVAEod5Hq5iS1d gqjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743629174; x=1744233974; 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=AsgpuCeamfuItSE2ZQUt1xIIqI9RqAD/ZBJYfDWlNSI=; b=hQnOf/aM32ExiLXeKWS18qTeU5/W/aTd2FgDSQeXiz7BZnEFTonLvEz2uKyu3w1wGE VVFFxHKW8YIDdSWOFQzDUfog33cs89lP8bik9AdXwzEqdtVnOu75Ea7zJ1VxYMOHza3M kKBMYdf4AFtTvOtWW3CqWx+cWOj9mXxyioPw5OKKxHpDTXMhkGQw53UI/3186RDgw1PV 9ksFgYuavZEHwy6vKKxj1mHlNhB7NyP2TEeGNq0dm5s0yctmEtC7492fZFe+ih/COsNK Gd1V62gZE6UatGUQkcEPuISB0gGrTNdUFc/FxMGH5aLGgh4X2j/nqFS6nZ0+RVvTRbR7 GNWQ== X-Forwarded-Encrypted: i=1; AJvYcCVBR4ZiWBrOVlBVidO6ggPoHKlzAg44iKX+Caru8y5c+r+BKMSYP8ByJhcaI07qWytO/qtd8voOTLnMGW0ihIM=@freebsd.org X-Gm-Message-State: AOJu0YysBfU7Jjd06XAk2Hp0JFzLJD27doROEMQuIfySOU9MAhpHmhNb BD90PPqDQ5jrjq+/ZVYOxrWNr7jzzmOdLns9CTPIy+9fqeGZQxMOUtzpRL3BOaWxDOKehQQ/uue Oa1SaA4HBrb56SNyRZQQ8EdmkoHcNhT4= X-Gm-Gg: ASbGncvrmO9iJnEirvsj/J9EMMXO+uAvESzlenA7qgD/09mlg3ybcDaUbM47oel3Myt UE7x/q5f3igJ2y6h5Vh/hZCstOGzPoGiRYUHsGiavugSB1h64xMWfRTzza5/NGrfsBLQc7P6M3I 18Hia0KxisuplTnz7D+2+D+RJCRT2/9fbIqjEc/nLCN+5e8WFVkTlOgQZm0g== X-Google-Smtp-Source: AGHT+IHZdSQko1LzzFJ/2HW3cgMpTAuUI9ctTupnJ2DxJHiSjV8wNuop8l+XCGaovdJJDJyHCuXgjZmmhCcTkV7lMu8= X-Received: by 2002:a05:6402:d09:b0:5ed:5554:7c3b with SMTP id 4fb4d7f45d1cf-5f02b38ab59mr7333442a12.32.1743629173746; Wed, 02 Apr 2025 14:26:13 -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: Wed, 2 Apr 2025 14:26:03 -0700 X-Gm-Features: AQ5f1JpuqNjRaIRdRSOMHr3EEs3Tu2eStntMBKqT0M9ov3rCAXVFzMSpZ5T58zA 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-Spamd-Result: default: False [-3.99 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.997]; NEURAL_HAM_MEDIUM(-0.99)[-0.991]; 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)[]; TAGGED_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; FREEMAIL_FROM(0.00)[gmail.com]; DKIM_TRACE(0.00)[gmail.com:+]; MISSING_XM_UA(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::52b:from]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MID_RHS_MATCH_FROMTLD(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_COUNT_ONE(0.00)[1]; FREEMAIL_ENVFROM(0.00)[gmail.com] X-Rspamd-Queue-Id: 4ZSdGK0RZmz3kVx X-Spamd-Bar: --- On Tue, Apr 1, 2025 at 4:08=E2=80=AFPM Rick Macklem wrote: > > On Sat, Mar 29, 2025 at 1:22=E2=80=AFPM Rick Macklem wrote: > > > > 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 libarchi= ve, 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 attrib= utes > > > > > > > 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 pr= obably needs > > > > > > to be tweaked to use the different syscall API so that it can h= andle large > > > > > > attributes and maybe the attribute's mode. (someday, maybe?) > > > > > > > > > > I believe libarchive has been updated in FreeBSD since October 20= 20, > > > > > 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 hour= s), I > > > > > would probably volunteer to update the libarchive code. > > > > > > > > > > > > Just one data point here: HardenedBSD uses filesystem extende= d > > > > > > > attributes to toggle certain exploit mitigations on a per-app= lication > > > > > > > basis. That's why we added support to libarchive: so we can s= hip > > > > > > > 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 (hbsdcontro= l) > > > > > was recently taught about the user namespace. The kernel side onl= y > > > > > 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 work= s > > > and again is bitten by more important items on my TODO list. It mainl= y > > > 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 ad= d > > > myself to it so I can more easily keep informed. > > Not yet. I am still cleaning things up and testing. > I have put the VFS/syscall changes up in phabricator under D49583. > I listed a few reviewers, but anyone is welcome to review/comment on it. I have just committed this to main as 2ec2ba7e232d. However, there is a ver= y slight difference (definition of some flags) from the test patches. I will update the test patches as soon as kib@ commits his struct stat patc= h in D49651. This shouldn't take long. Thanks go to kib@ for reviewing this. After that there will two patches to be applied on top of a current main kernel src. https://people.freebsd.org/~rmacklem/zfs-xattr.patch https://people.freebsd.org/~rmacklem/nfs-xattr.patch I will put the ZFS patch up on phabricator soon, as a first step towards ge= tting it pulled into openzfs. rick > > rick > > > 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 e= lse. > > (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_We= bb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc From nobody Wed Apr 2 23:54:06 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 4ZShY63tCxz5s6Dd for ; Wed, 02 Apr 2025 23:54:18 +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 4ZShY60qPFz48c4 for ; Wed, 02 Apr 2025 23:54:18 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=dDUzgJfu; 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-5e61d91a087so626224a12.0 for ; Wed, 02 Apr 2025 16:54:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1743638057; x=1744242857; 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=LgPjTC1sZlVpx+gMNWfZH8aJVJcTpR5yVFDqmmuTt7M=; b=dDUzgJfuq1UqAcb3AHko9iXqOARuEvzFWq+UC2gbkjHH32Iw5VmppoMmTHtxUH6P5z b409ljO9wk9F2T5DupPEIynP8jo8DcWE8HPsd/mqQJd3TSPDhHELc/H0Pqh14ykBbNCz CejEq1TMWLsZgDZwvAV/vOEOB/ZMqWVynsC5RQLQkPHLe17sizoXek3/8FyAGqGWNd+d +8ACAYsx9uZ/mxpXAXZMOaHshOFk8xHwQHwW58bd1jqVRuxFy0kMCfPcJYEtyQ6LkjiJ 0Ku8r+cTRJVguXk7UwGaqFmr0LMOa0PCotSJx6dbohfOw5JRWv8LZVDrldzMomjR3kMW 1XDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743638057; x=1744242857; 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=LgPjTC1sZlVpx+gMNWfZH8aJVJcTpR5yVFDqmmuTt7M=; b=GlVViTkRGfrd1A8SrMSJvY2TDG6a3qcFMOAg9o0ynxfj3jWOH5sRczCGf7aMhYujwh tse/bi+zXPHm0qavXsiHwRV+9eLO7u3ZY3VibbVM6S/MfePQ5zKycZYuf2f8Gerq+oF9 14z/7NXxpv0pdyDMUuLZCkzXRdC2JCKZF/Whpx4aCY6DJ7I0ha2SMkAptgF+1R+j82aO FfbhcbKbTAgsYUNiicNJyEmEgQZZINlU3t/x/YVAObJOIjgxcaFqrst7fAY6hCrCVOjC vMXDM0FHynh121m5CB8TnIxRqc5cQkknM30Gx6lJ4POpw+FAprKaa/kdsOwdZGidsmwd TXsQ== X-Forwarded-Encrypted: i=1; AJvYcCXJGN634UqQF0M4ZmUZEfue8RYpgrna8ZoxLaev956m2QLzLEEh24u1owEJV3N4M/+U1IOoKaCqeKxQVJ+p5ew=@freebsd.org X-Gm-Message-State: AOJu0YzfdYVadJ8sLWT54Otqydi/2BQbNvjlpGFvnBXzeVyh8okR6oMW uH+wTwRsZuSgkhBYYfF2xMk/QBQF4SBK3CbEBZsfPBOWjcUA7Yd+MrVN0cJjE675hiv4fVNZP5Y 2zQN2OvNrxJv7q1UZ0HIcnK6Aeg== X-Gm-Gg: ASbGnctDCSREjj7vOF3+MEdMqPCYWrnZSRFTCyZVUEueggYPhjKKP1ovjbjlGKLR0CH bSkPSi7j06WEdRYkfhvkFNxcbEV68dFBtxvTC0jtWd/JvZakK6L3wl+FmEhL58yhIOAnoQy5Z8i 94xuC6W4tcNiHPMORhNx7JFdcO7ZGjWYadLAg5kIolYpRs8f4oD/X5PLgMveeJLpyOJIAr X-Google-Smtp-Source: AGHT+IFSfT0IwUCP2Dp0bMdGN0vCzOshmJYLcp98WcmChqJVOp0H2JOU4nQkssojMBL5VZ6v037u6ioyV/TXSzYtygA= X-Received: by 2002:a05:6402:2709:b0:5e5:be7f:a1f6 with SMTP id 4fb4d7f45d1cf-5f087154ae9mr301662a12.1.1743638056443; Wed, 02 Apr 2025 16:54: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: <410014e4-75a6-4923-8f84-3935cab41c31@blastwave.org> <3dso3cojzxnylcfmpmgwzizp4omzpmnbfgz3zt5pvgeur4wss6@kblfkmtssebw> In-Reply-To: From: Rick Macklem Date: Wed, 2 Apr 2025 16:54:06 -0700 X-Gm-Features: AQ5f1Jq1PCtFsAQGB578Nfd4j1gQDRpGzbnT94jlcL_-GlMVhch5VjXP0qJy2Hc 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-Spamd-Result: default: False [-3.33 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-0.91)[-0.911]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.42)[-0.420]; 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)[]; TAGGED_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; FREEMAIL_FROM(0.00)[gmail.com]; DKIM_TRACE(0.00)[gmail.com:+]; MISSING_XM_UA(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::52a:from]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MID_RHS_MATCH_FROMTLD(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_COUNT_ONE(0.00)[1]; FREEMAIL_ENVFROM(0.00)[gmail.com] X-Rspamd-Queue-Id: 4ZShY60qPFz48c4 X-Spamd-Bar: --- On Wed, Apr 2, 2025 at 2:26=E2=80=AFPM Rick Macklem wrote: > > On Tue, Apr 1, 2025 at 4:08=E2=80=AFPM Rick Macklem wrote: > > > > On Sat, Mar 29, 2025 at 1:22=E2=80=AFPM Rick Macklem wrote: > > > > > > 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 libarc= hive, 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 attr= ibutes > > > > > > > > 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 tha= t. > > > > > > > > > > > > Since HardenedBSD follows FreeBSD closely (we sync every six ho= urs), I > > > > > > would probably volunteer to update the libarchive code. > > > > > > > > > > > > > > Just one data point here: HardenedBSD uses filesystem exten= ded > > > > > > > > attributes to toggle certain exploit mitigations on a per-a= pplication > > > > > > > > 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 (hbsdcont= rol) > > > > > > was recently taught about the user namespace. The kernel side o= nly > > > > > > supports system namespace. So the user namespace support in > > > > > > hbsdcontrol is somewhat meaningless. I do plan to eventually ge= t to > > > > > > the kernel side, but my TODO list continues growing. :-) > > > > > Ok, this wouldn't be affected by the patches I've been doing, sin= ce they > > > > > handle user space only. (system space will still work, but only v= ia 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 wo= rks > > > > and again is bitten by more important items on my TODO list. It mai= nly > > > > serves as a proof-of-concept for a weird data exfiltration techniqu= e. > > > > 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. > > I have put the VFS/syscall changes up in phabricator under D49583. > > I listed a few reviewers, but anyone is welcome to review/comment on it= . > I have just committed this to main as 2ec2ba7e232d. However, there is a v= ery > slight difference (definition of some flags) from the test patches. > I will update the test patches as soon as kib@ commits his struct stat pa= tch > in D49651. This shouldn't take long. Thanks go to kib@ for reviewing this= . > > After that there will two patches to be applied on top of a current > main kernel src. > https://people.freebsd.org/~rmacklem/zfs-xattr.patch > https://people.freebsd.org/~rmacklem/nfs-xattr.patch > > I will put the ZFS patch up on phabricator soon, as a first step towards = getting > it pulled into openzfs. The ZFS patch is now on phabricator in D49654. I listed Alexander and Andre= w as reviewers, but anyone should feel free to review it. Thanks for your comments sofar, rick > > rick > > > > > rick > > > > > Also, there ahs not been much response related to the question "shoul= d this > > > go in FreeBSD?". Dennis doesn't sounds like a "no" and the two poster= s 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/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc From nobody Thu Apr 3 23:52:35 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 4ZTJSl6X8mz5sh2d for ; Thu, 03 Apr 2025 23:52:39 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (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 4ZTJSl1MLCz47Km for ; Thu, 03 Apr 2025 23:52:38 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=hardenedbsd.org header.s=google header.b=OTMWmoIs; dmarc=none; spf=pass (mx1.freebsd.org: domain of shawn.webb@hardenedbsd.org designates 2607:f8b0:4864:20::d31 as permitted sender) smtp.mailfrom=shawn.webb@hardenedbsd.org Received: by mail-io1-xd31.google.com with SMTP id ca18e2360f4ac-85db3475637so78956439f.1 for ; Thu, 03 Apr 2025 16:52:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd.org; s=google; t=1743724358; x=1744329158; 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=xv/prJ39mGlqqKhuvilpDle8DVIMfRlohMvAyk5WUXI=; b=OTMWmoIs40mCMYE612CC/xiiOe9BSmvgGrwmXimYiLIPmFRezwr4qhtf4NpilN0iE4 JSuqJrNNlIeucSs1UekF76jQ4hQUVgP4IDjjaPGDw3fM7Qhlaj7Ndx1wts9YW17FxHc3 cNpAKxFzWVCJFbJXqrTpY2YDa05r2M4FF/hVhK4Ojz+7qLAiWvhuDM+HYVW5YeLwYCQy +LiaKCgsZto5CnqVvpkkJIK3wnvU1sKkH0AxgIJmjbfr03A3Rz7qNe1FK6Z2hExJPfrq Uyg48zFJ6KLsye7KYI8Duu6X67ylpWkXfmv6bahIjbzeOBm18ILCCia114wFzS30q+yk /rZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743724358; x=1744329158; 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=xv/prJ39mGlqqKhuvilpDle8DVIMfRlohMvAyk5WUXI=; b=m5vLDw4vllUY+JCwiBj8DyC3u9B8ieZGAalcsfYZ2Zjx+ZI7Ql3rkack+ZQ6akASQW /AuBK2TN2KNihT90TBPbBro85LnZWdy10+4BPp8DccLp4QR2tC3mwLrLNEmFWmA+1YSQ ykrhrt7v7wVgYn+NyiPynJ681VPv5ONKpVZeLaNqyXnKPygWtBR/kgRNI9I53Tov3GwL XkD4pMF6kfTqK1pqu4JPhm06tb8xgg8vX5BsiyqDoZAdb4NpEx6KDCBMBqDo1dSFMjAd OAtIZqrVf9eoj/aDWIEboCGLpeqZTRet3NC+UHDxTye4Kswn0q4/5h8jfhXm+JNY0R52 JBRg== X-Gm-Message-State: AOJu0Yx+xQgE4zwA8Qkyvvj1fug0tqyJnwM4lzcWjdiiU7ERIkxtcSGh +Bl06pUpQ6kZZ7F0Md4IFvywOFeViLzFDDqjwMMGLCTStBcWgdSo8KjbR1lMZCHP6g05etyGXjJ QIpA= X-Gm-Gg: ASbGncuGtmd6jHaxeyK38elVw6amF2MJ580FJuZBEqZIz8WJGn7acdei1msVhsgRLBU D8vIfjYNjroulILKvWUKHy28C41YLRnkeKiSoDZExT0U2LxxFDsWCKKYlqUQaNYoRqlTFkaLrBj GpgdCUd+NtzCzAyUHVcxR7qVBI95tr0vPUijBAFptItPVRwSNeYatyt/Rq8zZ7+xeGt6G687uc4 KbYHV6kcfREInNpyHtb9QZvPgzvcrDuSprB8nkMbW1gSgAOqaeaYv9Rn0rOWammpsQryAPzwe/X FnBgzsEzVV/q/xDoMsiuWNOvqok= X-Google-Smtp-Source: AGHT+IHfFfZQ0XEkjrQ3P9hHP4fiU37ZhQztdD8tHZxL9uYsX69Cbe410UQReTBxh7GcQA6hGaE7hw== X-Received: by 2002:a05:6e02:1fe1:b0:3d4:6ed4:e0a with SMTP id e9e14a558f8ab-3d6e3f999famr16909645ab.4.1743724357852; Thu, 03 Apr 2025 16:52:37 -0700 (PDT) Received: from mutt-hbsd ([2001:470:4001:1::95]) by smtp.gmail.com with ESMTPSA id e9e14a558f8ab-3d6de95e818sm5459715ab.45.2025.04.03.16.52.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 03 Apr 2025 16:52:36 -0700 (PDT) Date: Thu, 3 Apr 2025 23:52:35 +0000 From: Shawn Webb To: Rick Macklem Cc: FreeBSD CURRENT Subject: Re: Heads Up: commit 2ec2ba7e232d just hit main 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="umrfpxrhgoubq5im" Content-Disposition: inline In-Reply-To: X-Spamd-Result: default: False [-5.10 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.997]; MID_RHS_NOT_FQDN(0.50)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; R_DKIM_ALLOW(-0.20)[hardenedbsd.org:s=google]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; RCPT_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[hardenedbsd.org:+]; ARC_NA(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; DMARC_NA(0.00)[hardenedbsd.org]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MIME_TRACE(0.00)[0:+,1:+,2:~]; 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::d31:from] X-Rspamd-Queue-Id: 4ZTJSl1MLCz47Km X-Spamd-Bar: ----- --umrfpxrhgoubq5im Content-Type: text/plain; protected-headers=v1; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: Heads Up: commit 2ec2ba7e232d just hit main MIME-Version: 1.0 On Wed, Apr 02, 2025 at 01:51:26PM -0700, Rick Macklem wrote: > The commit 2ec2ba7e232d just hit main. I do not think it will > cause problems, but it is fairly large. >=20 > Man page updates will be done as separate commits. >=20 > Hopefully this will not cause grief, rick Hey Rick, The patch review test plan mentions a patch to ZFS itself to support named attributes. Is that patch available somewhere? Thanks, --=20 Shawn Webb Cofounder / Security Engineer HardenedBSD Signal Username: shawn_webb.74 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 --umrfpxrhgoubq5im Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEA6TL67gupaZ9nzhT/y5nonf44foFAmfvHz4ACgkQ/y5nonf4 4fpmxhAAjOqyViX4VY+2J3cj4wvMPeqIN5nyS2wx3b0PMQg3JYD+vFm0vbXqYqEP OwYqqYe2R7ddhpHUNXIxVMukX83ne/rkhrWMYD7wUhd6PINPI2D9idVHj9ekdHsY 38XQgBd4U4uvBZNguucnMz7I7fhfoKtfevPSztCj9KWM585bKzEAnYzIaDmTRTQY EKOJULsVUAfHKeqJQpImIZ9NBDeyNBLvMAwqsYky6aZXdpYtAvIIKd2XfpULpuSY pvvb4rk6lt45NguJZwPvwXW9pMfQ+g4i58BAQRRiCaOVvMNZHCJv10i+R3ScoUU4 rjZIKVUB5P+2MYdNSD4eg1o+tP3vACpp3mWUBlvYyl5gY0u6M6sW2XoRnn9FTdAl /9qgipWdLUcHKcliIwT66stYOE4s80a+hyMmOt22wwv6nsmaLErWb0IiSOROSx1N bOes+pMm4OFJeUemTz2NRwlfIkTVtCUjKIq6bfs5kSTjftod9PHPz7oQOS0BhH/J FT4UcZhqRb0yHINlk2D9+MUE+trsq279ufJtQ/CUUyVmFLjw/XXpVz8ij4Dn6qV0 IswEzG3KfztsAUqySSrHyOZ7/Wy0njysQnuY1+ARaNP/vdjsrxX9ttIWuTi09EBw kW36PyFgq7KMFrAiLqs8fnqc9oxasQeq/06B7lX9vWLgavr9Xl8= =fpgt -----END PGP SIGNATURE----- --umrfpxrhgoubq5im-- From nobody Fri Apr 4 01:12:59 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 4ZTLFh0vDJz5smrJ for ; Fri, 04 Apr 2025 01:13:12 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (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 4ZTLFg6Lwqz3N88 for ; Fri, 04 Apr 2025 01:13:11 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x534.google.com with SMTP id 4fb4d7f45d1cf-5e6ff035e9aso2924749a12.0 for ; Thu, 03 Apr 2025 18:13:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1743729190; x=1744333990; 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=G6aLwNCHF4x2gdqAK/lIu0ijgoPQyBq8FTVFHl5KsF4=; b=kgFHjWlKQbjgwhNVIK/oNYoEhcc6sMl5NWbJpXHYHeZ9zkh4eckrNKPeOLRv8cKfNz ZZ90cZm3FR3odxi+tv9ETuZjWb22iyNOCLv1S6x/d4hAT4PXdvyi9yJiDiYjLAmk3w7q 0kWnS8hFp9yJ/vi5rSOpJ6dwj5Jnnb8l/h6RxgIGCnDIia0t4JezBmuO6QhS/m4XnhsG /fRBEfNL1lM0+66ecx4kwqtN1UiEAW7uxtI4na2+LuHZYGUwc7TLnNotT4SMrbxyrNkK u7yruWUf4yH5PbdbhmK1AmcmfdaDJgagOIKUKOBU7ki4DL9tab0WruCb8CxQ96dyf/Vh xOYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743729190; x=1744333990; 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=G6aLwNCHF4x2gdqAK/lIu0ijgoPQyBq8FTVFHl5KsF4=; b=NuHCjj3szh+LpuTOkxtEsD4Ry1HxbdopzWQeFUBTgrNrkVKrIC/rYdYHQTMlEHrScJ ZqyHXpUJP2ElHjOzQbC/P63OHrf90UZxpypCi+9OFkK/vcMvQEJqsJrFECyKIK3e6T4f 1+DVTSq7hCwRMJmIgpWi5EsKV9b2D8Jbn6xUUCZJvV0qpw37hAfMgUkTeIiwnz/rVMU8 hRGO4S2VTkdCxRPdMDS1OsP6UUwKPCAC9ra4PyOxhBODr/1ZpdoUnp7LhbmL0kLIivfj FOvL2xzuZFJ+m5hwl60WY79kaDPYHUWG0TjmmwgBBXSFxPEZJNhAkz4BPmIkzvmo4OnK diXA== X-Gm-Message-State: AOJu0YyR7JsZ2sDVV+VrBpbcpLJUontAVj7jRYZWXE691cRivM0BAmdk lmfX6sBFU3XvxeK2tdrVwOHk77zFJNt95149R2qaxoFUai8to/UhWiD5jEfGqP2f5LR5iFGSKjF wlXKgpGO/wRO6AV3ViU14LLDx84MWaAQ= X-Gm-Gg: ASbGncsaC/FxlZTd0lGB5WteSvV2i6wnU+Bo6LZ9UExJ1NFSk4lpKDgg7gdsBZB08Yu QyJbnYIcDg5o2au5F16PLvggKYqiKGc4Wqr+YMavadHV+pr4Fz6ba9UOQlBZVXer9XNaRGfGNkl COvanSZpxLv4WfD7C3IYcj3u3JCWeSeMssZzsQylsnzknIejsf14vxvnRxTQ== X-Google-Smtp-Source: AGHT+IHG8I1/EJjZZjKu5ghpjAevvCVwgoYI6uBNW3wS1GvE05jK4op+MLoxh5tDNoT1YHD35eW7DULW8pZ/Tv3fDu4= X-Received: by 2002:a05:6402:2807:b0:5e0:9959:83cd with SMTP id 4fb4d7f45d1cf-5f0b3e3684bmr788199a12.21.1743729190062; Thu, 03 Apr 2025 18:13:10 -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, 3 Apr 2025 18:12:59 -0700 X-Gm-Features: ATxdqUHJysElECk3DwMLfTBBM-3Nxzp3BIpmzpdidB2svACtUpmQ8Dvwkj_yBh4 Message-ID: Subject: Re: Heads Up: commit 2ec2ba7e232d just hit main To: Shawn Webb Cc: FreeBSD CURRENT 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: 4ZTLFg6Lwqz3N88 X-Spamd-Bar: ---- On Thu, Apr 3, 2025 at 4:52=E2=80=AFPM Shawn Webb wrote: > > On Wed, Apr 02, 2025 at 01:51:26PM -0700, Rick Macklem wrote: > > The commit 2ec2ba7e232d just hit main. I do not think it will > > cause problems, but it is fairly large. > > > > Man page updates will be done as separate commits. > > > > Hopefully this will not cause grief, rick > > Hey Rick, > > The patch review test plan mentions a patch to ZFS itself to support > named attributes. Is that patch available somewhere? The ZFS patch is currently in phabricator as D49654. Feel free to review it. It can also be found at: https://people.freebsd.org/~rmacklem/zfs-xattr.patch (this is a smaller diff which can be applied to an up-to-date main src tree easily) Then the NFS patch is found at: https://people.freebsd.org/~rmacklem/nfs-xattr.patch rick > > Thanks, > > -- > Shawn Webb > Cofounder / Security Engineer > HardenedBSD > > Signal Username: shawn_webb.74 > 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 Fri Apr 4 08:47: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 4ZTXL76wbfz5rvTC for ; Fri, 04 Apr 2025 08:47:43 +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 4ZTXL6318Xz3ShS for ; Fri, 04 Apr 2025 08:47:42 +0000 (UTC) (envelope-from dclarke@blastwave.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=blastwave.org header.s=default header.b=SeAsXj8A; 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 5348la8c094279 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Fri, 4 Apr 2025 04:47:37 -0400 (EDT) (envelope-from dclarke@blastwave.org) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=blastwave.org; s=default; t=1743756458; bh=t1luk/cGCDwGpLSyZybywc1gFVViPPpWIaAuYlXRPpg=; h=Date:Subject:To:References:From:In-Reply-To; b=SeAsXj8AXbKJBhXRvr8v9/3uBabYYIWLhp8SoI4wOSR0c2CNXgrpdoHJuNRihdI4x 9hl+OOjyRrecyCLFlRTZ5k18x+kqbT9uCeCDpJ2En7+v3kf+YqirCcc52asK+EOQmZ W1HEBcw6xD+iF+DdjwtFMTa2QciwUSJgE88EWz/6qMBCCivEZr255le7NCpvpCsc3s xWghOUHMV/HgUnJj9wjZAcpPcJrNtwdVSwPYClnidVs6ApbzvSfEVzFpTcxK/Yk2zI bhff5zgxmSYqwDRdtijhwOy2zBdO3xNEb3m+mLSc07DWRJFTECXlzZKEHPsKz6QR+J 34z4agRvs/QzQ== Message-ID: Date: Fri, 4 Apr 2025 04:47:36 -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: Heads Up: commit 2ec2ba7e232d just hit main 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: 7bit X-oetec-MailScanner-Information: Please contact the ISP for more information X-oetec-MailScanner-ID: 5348la8c094279 X-oetec-MailScanner: Found to be clean X-oetec-MailScanner-From: dclarke@blastwave.org X-Spam-Status: No X-Spamd-Result: default: False [-4.60 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.90)[-0.899]; DMARC_POLICY_ALLOW(-0.50)[blastwave.org,quarantine]; RCVD_DKIM_ARC_DNSWL_MED(-0.50)[]; R_SPF_ALLOW(-0.20)[+mx]; RCVD_IN_DNSWL_MED(-0.20)[108.160.241.186:from]; R_DKIM_ALLOW(-0.20)[blastwave.org:s=default]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; HAS_ORG_HEADER(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[blastwave.org:+]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:812, ipnet:108.160.240.0/20, country:CA]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; ARC_NA(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[] X-Rspamd-Queue-Id: 4ZTXL6318Xz3ShS X-Spamd-Bar: ---- On 4/3/25 19:52, Shawn Webb wrote: > On Wed, Apr 02, 2025 at 01:51:26PM -0700, Rick Macklem wrote: >> The commit 2ec2ba7e232d just hit main. I do not think it will >> cause problems, but it is fairly large. >> >> Man page updates will be done as separate commits. >> >> Hopefully this will not cause grief, rick > > Hey Rick, > > The patch review test plan mentions a patch to ZFS itself to support > named attributes. Is that patch available somewhere? > > Thanks, > I am a little confused but the features seem to be there even if I do not recall how to test : titan# uname -apKU FreeBSD titan 15.0-CURRENT FreeBSD 15.0-CURRENT #0 main-n276246-628d1501f7ec: Fri Apr 4 06:57:29 GMT 2025 root@titan:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 amd64 1500035 1500035 titan# Create a new ZPool and then a ZFS filesystem with xattr=on : titan# camcontrol devlist at scbus0 target 0 lun 0 (pass0,ada0) at scbus1 target 0 lun 0 (pass1,ada1) at scbus2 target 0 lun 0 (ses0,pass2) at scbus6 target 0 lun 0 (ses1,pass3) at scbus7 target 0 lun 1 (pass4,nda0) titan# titan# gpart create -s GPT /dev/ada0 ada0 created titan# gpart create -s GPT /dev/ada1 ada1 created titan# titan# gpart show /dev/ada0 => 40 39063650224 ada0 GPT (18T) 40 39063650224 - free - (18T) titan# titan# gpart show /dev/ada1 => 40 39063650224 ada1 GPT (18T) 40 39063650224 - free - (18T) titan# titan# gpart add -t freebsd-zfs -l fbsd15zfs0 /dev/ada0 ada0p1 added titan# gpart add -t freebsd-zfs -l fbsd15zfs1 /dev/ada1 ada1p1 added titan# titan# gpart show -l /dev/ada0 => 40 39063650224 ada0 GPT (18T) 40 39063650224 1 fbsd15zfs0 (18T) titan# titan# gpart show -l /dev/ada1 => 40 39063650224 ada1 GPT (18T) 40 39063650224 1 fbsd15zfs1 (18T) titan# titan# zpool create -O compression=zstd -O checksum=sha512 \ > -O atime=off -O xattr=on \ > -o autoexpand=off -o autoreplace=on -o failmode=continue \ > -o listsnaps=off \ > -m none tank mirror /dev/ada0p1 /dev/ada1p1 titan# zpool list NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT tank 18.2T 588K 18.2T - - 0% 0% 1.00x ONLINE - titan 460G 44.7G 415G - - 0% 9% 1.00x ONLINE - titan# titan# zfs create -o mountpoint=/opt/xattr -o canmount=on \ > -o checksum=sha512 -o compression=zstd \ > -o atime=on -o exec=on -o setuid=on -o xattr=on -o copies=1 \ > tank/xattr titan# titan# zfs list -r tank NAME USED AVAIL REFER MOUNTPOINT tank 696K 18.1T 96K none tank/xattr 96K 18.1T 96K /opt/xattr titan# titan# zfs set quota=64G tank/xattr titan# zfs list -r tank NAME USED AVAIL REFER MOUNTPOINT tank 756K 18.1T 96K none tank/xattr 96K 64.0G 96K /opt/xattr titan# mkdir /opt/xattr/test titan# getfacl /opt/xattr/test # file: /opt/xattr/test # owner: root # group: wheel owner@:rwxp--aARWcCos:-------:allow group@:r-x---a-R-c--s:-------:allow everyone@:r-x---a-R-c--s:-------:allow titan# titan# chgrp devl /opt/xattr/test titan# getfacl /opt/xattr/test # file: /opt/xattr/test # owner: root # group: devl owner@:rwxp--aARWcCos:-------:allow group@:r-x---a-R-c--s:-------:allow everyone@:r-x---a-R-c--s:-------:allow titan# titan# setfacl -m group:devl:rwx /opt/xattr/test setfacl: /opt/xattr/test: branding mismatch; existing ACL is NFSv4, entry to be merged is POSIX.1e titan# titan# well ooops .... what was the idea here again ?? -- -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken From nobody Fri Apr 4 13:37: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 4ZTfmx5p94z5sHnc for ; Fri, 04 Apr 2025 13:37:53 +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 4ZTfmx3zsdz43GY for ; Fri, 04 Apr 2025 13:37:53 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x52b.google.com with SMTP id 4fb4d7f45d1cf-5ec9d24acfbso5780900a12.0 for ; Fri, 04 Apr 2025 06:37:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1743773872; x=1744378672; 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=WCTGY8/a7kZe4m0qvhIMHjMhBOg1GkoJ2iFs5WzcOII=; b=e1XDpR/nfqdEpDkPzeuAom/TQEH97PP7Qga3LidYOGpUw1UEsXYGszzSXdO3VqlHZ+ 9gMV7lgQuY6sWdVWYObGlTFBORLTqxPaf6Ah6xg1NqrPnVdHpfsB/NZC5bMvSKEi8LW2 gG8t87cft56TAyGqMEhbT95HLuZKD/4T8nvOQ+Tbl8F4v6YxU/EhIkcoSP2Pukqz7Wuy VbljK4qiJD+LkJ/8904tKmmItBr8Ko9rZFXEZ57ftVAtwMbM54UWPL/NgjeU9a0/k90y bin+j7h4VxW2rj1j/piJNeRwOkJ4Xdt96lXfiZEs3SzcGbOdbB0w0/+hY/TpX306v1aq zn5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743773872; x=1744378672; 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=WCTGY8/a7kZe4m0qvhIMHjMhBOg1GkoJ2iFs5WzcOII=; b=CUNz3knT9J3MM8pMiHrBDyywP3JzEeq+pnFVG0fgRQqxBc3ppeI2767coRDfdX94Ax HP1Skz3VZkAVprmt/Qls1OMahKWrS/m8YMMjwiZJkH3lVpacYQ8b4cx0Wl7NPYDnoq0I 4IItOmA2H3zfQuc1hiCUZCatYLhc23JCqSewIZ56+SDcIc/EQ6/O/Y17HHhweV5CMNn9 vLo3MdJebYgEykOyYmU3fCjzsI9xKffs68LlrtRNXO74qrQ9miaia6g90n+wjZeiD5U0 hfeOPp6PrlwptJE5EQPP1rXcbc2Ilq/X/d03CBrXvF1ZtZYvzghK7TGnxoa4EojNK78b R2+g== X-Gm-Message-State: AOJu0YwtghFXR42E8xGUPCFFWMSliV3zeMwBE7hysCcm0BP474dETS5x lwj3krL3NL51A3IcqMjO3jP8ZIj5iUhfSunGCpTx/nYEYcLJAJMOGxdOUXYFPsh2hLjEZ1JhUGs KDYvWq76HDLNKs1sF/fsz7BgwuaN+wjE= X-Gm-Gg: ASbGncsbJjOBs23jyH/Mw9Y0VjCJNtGMz3LC51DM4iwXYuK5laM/YE4GsqldURh9ft5 TQaRte5Sx5JTW9fMYOfb7Irtd7k63O/msOPV+cEIRDYMN/P+0Bb1JlO7clkd+4DE/n+iJDboVUb breDn5rxkYJkGtcmc5ANONDy+kOjI5osfP42gN9qqdDrXrJxF6/ejt0RwMzD0cXBqT0ak8 X-Google-Smtp-Source: AGHT+IFHoN3fWYlmQOubeCFYbNbhUIrD1mMB5CqsWKrqckeSlph0L7o04FNH6rFST6Ut8GnNHQv8lAA3bUVd3RtOFN4= X-Received: by 2002:a05:6402:1ed5:b0:5e0:752a:1c7c with SMTP id 4fb4d7f45d1cf-5f08412c7bfmr6341349a12.1.1743773871770; Fri, 04 Apr 2025 06:37:51 -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, 4 Apr 2025 06:37:41 -0700 X-Gm-Features: ATxdqUF0oESy-x0utIAbtNm7lZp3Zm_Xex755Tb_8XmyRGJxIbpWUWvEkkxv4Ag Message-ID: Subject: Re: Heads Up: commit 2ec2ba7e232d just hit main 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: 4ZTfmx3zsdz43GY X-Spamd-Bar: ---- On Fri, Apr 4, 2025 at 1:48=E2=80=AFAM Dennis Clarke wrote: > > On 4/3/25 19:52, Shawn Webb wrote: > > On Wed, Apr 02, 2025 at 01:51:26PM -0700, Rick Macklem wrote: > >> The commit 2ec2ba7e232d just hit main. I do not think it will > >> cause problems, but it is fairly large. > >> > >> Man page updates will be done as separate commits. > >> > >> Hopefully this will not cause grief, rick > > > > Hey Rick, > > > > The patch review test plan mentions a patch to ZFS itself to support > > named attributes. Is that patch available somewhere? > > > > Thanks, > > > > I am a little confused but the features seem to be there even if I do > not recall how to test : > > titan# uname -apKU > FreeBSD titan 15.0-CURRENT FreeBSD 15.0-CURRENT #0 > main-n276246-628d1501f7ec: Fri Apr 4 06:57:29 GMT 2025 > root@titan:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 amd64 1500035 > 1500035 > titan# > > > Create a new ZPool and then a ZFS filesystem with xattr=3Don : > > titan# camcontrol devlist > at scbus0 target 0 lun 0 (pass0,ada0) > at scbus1 target 0 lun 0 (pass1,ada1) > at scbus2 target 0 lun 0 (ses0,pass2) > at scbus6 target 0 lun 0 (ses1,pass3) > at scbus7 target 0 lun 1 (pass4,nd= a0) > titan# > > titan# gpart create -s GPT /dev/ada0 > ada0 created > titan# gpart create -s GPT /dev/ada1 > ada1 created > titan# > titan# gpart show /dev/ada0 > =3D> 40 39063650224 ada0 GPT (18T) > 40 39063650224 - free - (18T) > > titan# > titan# gpart show /dev/ada1 > =3D> 40 39063650224 ada1 GPT (18T) > 40 39063650224 - free - (18T) > > titan# > titan# gpart add -t freebsd-zfs -l fbsd15zfs0 /dev/ada0 > ada0p1 added > titan# gpart add -t freebsd-zfs -l fbsd15zfs1 /dev/ada1 > ada1p1 added > titan# > titan# gpart show -l /dev/ada0 > =3D> 40 39063650224 ada0 GPT (18T) > 40 39063650224 1 fbsd15zfs0 (18T) > > titan# > titan# gpart show -l /dev/ada1 > =3D> 40 39063650224 ada1 GPT (18T) > 40 39063650224 1 fbsd15zfs1 (18T) > > titan# > titan# zpool create -O compression=3Dzstd -O checksum=3Dsha512 \ > > -O atime=3Doff -O xattr=3Don \ > > -o autoexpand=3Doff -o autoreplace=3Don -o failmode=3Dcontinue \ > > -o listsnaps=3Doff \ > > -m none tank mirror /dev/ada0p1 /dev/ada1p1 > titan# zpool list > NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP > HEALTH ALTROOT > tank 18.2T 588K 18.2T - - 0% 0% 1.00x > ONLINE - > titan 460G 44.7G 415G - - 0% 9% 1.00x > ONLINE - > titan# > > titan# zfs create -o mountpoint=3D/opt/xattr -o canmount=3Don \ > > -o checksum=3Dsha512 -o compression=3Dzstd \ > > -o atime=3Don -o exec=3Don -o setuid=3Don -o xattr=3Don -o copies=3D1 = \ > > tank/xattr > titan# > titan# zfs list -r tank > NAME USED AVAIL REFER MOUNTPOINT > tank 696K 18.1T 96K none > tank/xattr 96K 18.1T 96K /opt/xattr > titan# > titan# zfs set quota=3D64G tank/xattr > titan# zfs list -r tank > NAME USED AVAIL REFER MOUNTPOINT > tank 756K 18.1T 96K none > tank/xattr 96K 64.0G 96K /opt/xattr > titan# mkdir /opt/xattr/test > titan# getfacl /opt/xattr/test > # file: /opt/xattr/test > # owner: root > # group: wheel > owner@:rwxp--aARWcCos:-------:allow > group@:r-x---a-R-c--s:-------:allow > everyone@:r-x---a-R-c--s:-------:allow > titan# > titan# chgrp devl /opt/xattr/test > titan# getfacl /opt/xattr/test > # file: /opt/xattr/test > # owner: root > # group: devl > owner@:rwxp--aARWcCos:-------:allow > group@:r-x---a-R-c--s:-------:allow > everyone@:r-x---a-R-c--s:-------:allow > titan# > > titan# setfacl -m group:devl:rwx /opt/xattr/test > setfacl: /opt/xattr/test: branding mismatch; existing ACL is NFSv4, > entry to be merged is POSIX.1e > titan# > titan# > > well ooops .... what was the idea here again ?? Well, this has nothing to do with my recent commit. ZFS has always supported NFSv4 ACLs (and not POSIX draft ACLs) on FreeBSD. (I actually am planning on a ZFS patch to add POSIX draft ACL support, but I haven't even started to work on it. I do have an IETF draft that adds POSIX draft ACL support to NFSv4.2.) If you look at the setfacl man page, it shows you how to set NFSv4 ACLs. ZFS has also always also supported extended attributes on FreeBSD. They are currently accessed via getextattr(1) and friends. The patch I just committed to main adds a different syscall/KAPI that allows manipulation of the extended attributes in a Solaris-like way, which is what NFSv4 calls "named attributes". Since the ZFS patch in not there yet, you cannot actually use this new syscall/KAPI (it will just fail with errors like ENOATTR). rick > > > -- > -- > Dennis Clarke > RISC-V/SPARC/PPC/ARM/CISC > UNIX and Linux spoken > From nobody Fri Apr 4 14:25:39 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 4ZTgrK00tdz5sMHN for ; Fri, 04 Apr 2025 14:25:52 +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 4ZTgrH2whYz47Z0 for ; Fri, 04 Apr 2025 14:25:51 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=N3wBLyaN; 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-5e6ff035e9aso4104532a12.0 for ; Fri, 04 Apr 2025 07:25:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1743776750; x=1744381550; 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=Bxbo/uZj0wBMpH/oTna14hgt8z1Sbhv0tDT/+j7/MSI=; b=N3wBLyaNOOEoFlZiIyM/nxoOaSzGuaHijEGk4V6BBH4f3wy95k34kR+1blejzxrDWR qUerwrooxFA9mxzV50Wahg3NhEQWT3pWzFdRbgKf+ukJ5nkVh40tTAo1P0ZhJ8hFqXIO caGVHflJS2htHKHAxDCYsOFr5/vnZvWDuV38rsmRjW0raUVSUzlYJc0QT3PxgtwLu0E5 e8ljY0CuBe1IBcGEqBdTXAKjDoSZ2q8IgX7dNRp5TcTP41dqR9isbsnEKDlTpz9ji1Uj 9K82c9+BGUlr50tMI8x7jovVZwiH/URSAw4H8Q/3HiX+vLzcXrNzeSbEOV80uWPi083L 30WA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743776750; x=1744381550; 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=Bxbo/uZj0wBMpH/oTna14hgt8z1Sbhv0tDT/+j7/MSI=; b=qU3qzA+lC7ZhbH5aQadImAUtP+cY/7jUQoeN4bAD6W3nZauGazZUL7onW0K2xglTLK MZqbI87GRKmV3QlrZpTzd2BsogPK/q9LwJCkWM4nEgJSGNXhX+zLPuDc/8SV/oidE6Qo Z6ibpbjKtY2eSVbVTdjRzx/Tqipd+480BmtrT9Jn8OF8lBtZoA9SaN8hnC+TDhFa14cs RW7k7qlEX2i4tFsC5eBl9oh7TmAfijUxk3eSpjD42hazbLw/QZrU6PC5kbq5/bS7HzkT lDG6CG/D10U3m2JM0fTqssNaFL906GkorvnEJOTXHrx8yxzlaSaIjFyCiKO3c/MmeW9w VBHQ== X-Gm-Message-State: AOJu0YzdLx+5WEgH9vVyp6keDOm8vr0YjnjSVaKyh9AA6/s5XkYwxulX KvHJd7dc6vk1ZzEWjtsraWd346CpvUJzem5jEJYXjJqK5ulUPybdrIPS61uPsPgAtfHj3bayyZY n3NQ4HBvym3UmA1U6IctjJ6+683ktidM= X-Gm-Gg: ASbGnctsGSUS3W5+diQFBV+lWbP0r/8rineR/hudklF8mQTo2o+0AnHRYz/FTIHUM/V 9HmRNPh1OrdP90pbi/FFFQPL29pHsEDcc4esUwGOyzKKb0CTRuecfE4QguapdzJD09TTgcirhdQ ftMluRkADV5vmp8gx/QlyCzfan5Q3Xdd560Ub4L1Tdr3/DoR8fz7cnkF4Kgg== X-Google-Smtp-Source: AGHT+IE9ccJnRTPT9u/ftDUMWu/iOoDldnZIagXJeRrEQZkPuIlSR+DjsgCX719GvtxBPbJoD1FAI8FyCbFpYYlJ2yE= X-Received: by 2002:a05:6402:34cd:b0:5e7:c773:ae35 with SMTP id 4fb4d7f45d1cf-5f0b3b6089dmr2784107a12.5.1743776749468; Fri, 04 Apr 2025 07:25:49 -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, 4 Apr 2025 07:25:39 -0700 X-Gm-Features: ATxdqUGXW6mWSxdn210X6MUb2DQBoramjG5W80tviwAbJzqJzsag1dSN8gIBQCU Message-ID: Subject: Re: Heads Up: commit 2ec2ba7e232d just hit main To: Dennis Clarke Cc: freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Result: default: False [-3.73 / 15.00]; NEURAL_HAM_LONG(-1.00)[-0.999]; NEURAL_HAM_MEDIUM(-1.00)[-0.997]; NEURAL_HAM_SHORT(-0.74)[-0.736]; 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)[]; RCPT_COUNT_TWO(0.00)[2]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_SOME(0.00)[]; TAGGED_FROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; MISSING_XM_UA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; 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::535:from] X-Rspamd-Queue-Id: 4ZTgrH2whYz47Z0 X-Spamd-Bar: --- On Fri, Apr 4, 2025 at 6:37=E2=80=AFAM Rick Macklem wrote: > > On Fri, Apr 4, 2025 at 1:48=E2=80=AFAM Dennis Clarke wrote: > > > > On 4/3/25 19:52, Shawn Webb wrote: > > > On Wed, Apr 02, 2025 at 01:51:26PM -0700, Rick Macklem wrote: > > >> The commit 2ec2ba7e232d just hit main. I do not think it will > > >> cause problems, but it is fairly large. > > >> > > >> Man page updates will be done as separate commits. > > >> > > >> Hopefully this will not cause grief, rick > > > > > > Hey Rick, > > > > > > The patch review test plan mentions a patch to ZFS itself to support > > > named attributes. Is that patch available somewhere? > > > > > > Thanks, > > > > > > > I am a little confused but the features seem to be there even if I do > > not recall how to test : > > > > titan# uname -apKU > > FreeBSD titan 15.0-CURRENT FreeBSD 15.0-CURRENT #0 > > main-n276246-628d1501f7ec: Fri Apr 4 06:57:29 GMT 2025 > > root@titan:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 amd64 1500035 > > 1500035 > > titan# > > > > > > Create a new ZPool and then a ZFS filesystem with xattr=3Don : > > > > titan# camcontrol devlist > > at scbus0 target 0 lun 0 (pass0,ada0= ) > > at scbus1 target 0 lun 0 (pass1,ada1= ) > > at scbus2 target 0 lun 0 (ses0,pass2= ) > > at scbus6 target 0 lun 0 (ses1,pass3= ) > > at scbus7 target 0 lun 1 (pass4,= nda0) > > titan# > > > > titan# gpart create -s GPT /dev/ada0 > > ada0 created > > titan# gpart create -s GPT /dev/ada1 > > ada1 created > > titan# > > titan# gpart show /dev/ada0 > > =3D> 40 39063650224 ada0 GPT (18T) > > 40 39063650224 - free - (18T) > > > > titan# > > titan# gpart show /dev/ada1 > > =3D> 40 39063650224 ada1 GPT (18T) > > 40 39063650224 - free - (18T) > > > > titan# > > titan# gpart add -t freebsd-zfs -l fbsd15zfs0 /dev/ada0 > > ada0p1 added > > titan# gpart add -t freebsd-zfs -l fbsd15zfs1 /dev/ada1 > > ada1p1 added > > titan# > > titan# gpart show -l /dev/ada0 > > =3D> 40 39063650224 ada0 GPT (18T) > > 40 39063650224 1 fbsd15zfs0 (18T) > > > > titan# > > titan# gpart show -l /dev/ada1 > > =3D> 40 39063650224 ada1 GPT (18T) > > 40 39063650224 1 fbsd15zfs1 (18T) > > > > titan# > > titan# zpool create -O compression=3Dzstd -O checksum=3Dsha512 \ > > > -O atime=3Doff -O xattr=3Don \ > > > -o autoexpand=3Doff -o autoreplace=3Don -o failmode=3Dcontinue \ > > > -o listsnaps=3Doff \ > > > -m none tank mirror /dev/ada0p1 /dev/ada1p1 > > titan# zpool list > > NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP > > HEALTH ALTROOT > > tank 18.2T 588K 18.2T - - 0% 0% 1.00x > > ONLINE - > > titan 460G 44.7G 415G - - 0% 9% 1.00x > > ONLINE - > > titan# > > > > titan# zfs create -o mountpoint=3D/opt/xattr -o canmount=3Don \ > > > -o checksum=3Dsha512 -o compression=3Dzstd \ > > > -o atime=3Don -o exec=3Don -o setuid=3Don -o xattr=3Don -o copies=3D= 1 \ > > > tank/xattr > > titan# > > titan# zfs list -r tank > > NAME USED AVAIL REFER MOUNTPOINT > > tank 696K 18.1T 96K none > > tank/xattr 96K 18.1T 96K /opt/xattr > > titan# > > titan# zfs set quota=3D64G tank/xattr > > titan# zfs list -r tank > > NAME USED AVAIL REFER MOUNTPOINT > > tank 756K 18.1T 96K none > > tank/xattr 96K 64.0G 96K /opt/xattr > > titan# mkdir /opt/xattr/test > > titan# getfacl /opt/xattr/test > > # file: /opt/xattr/test > > # owner: root > > # group: wheel > > owner@:rwxp--aARWcCos:-------:allow > > group@:r-x---a-R-c--s:-------:allow > > everyone@:r-x---a-R-c--s:-------:allow > > titan# > > titan# chgrp devl /opt/xattr/test > > titan# getfacl /opt/xattr/test > > # file: /opt/xattr/test > > # owner: root > > # group: devl > > owner@:rwxp--aARWcCos:-------:allow > > group@:r-x---a-R-c--s:-------:allow > > everyone@:r-x---a-R-c--s:-------:allow > > titan# This ACL did not change because "group@" refers to the group owner of the file. Since you changed the group owner, "group@" now refers to "devl". If you want to see this ACL change, you could "chmod 400 /opt/xattr/test" and then getfacl it again. > > > > titan# setfacl -m group:devl:rwx /opt/xattr/test > > setfacl: /opt/xattr/test: branding mismatch; existing ACL is NFSv4, > > entry to be merged is POSIX.1e > > titan# > > titan# > > > > well ooops .... what was the idea here again ?? > Well, this has nothing to do with my recent commit. > > ZFS has always supported NFSv4 ACLs (and not POSIX draft ACLs) > on FreeBSD. (I actually am planning on a ZFS patch to add POSIX > draft ACL support, but I haven't even started to work on it. I do have > an IETF draft that adds POSIX draft ACL support to NFSv4.2.) > > If you look at the setfacl man page, it shows you how to set NFSv4 > ACLs. Oh, and to clarify it, ACLs are stored as "system" extended attributes, which this new syscall/KAPI does not access and, in general, anything else can be stored in extended attributes as well. rick > > ZFS has also always also supported extended attributes on FreeBSD. > They are currently accessed via getextattr(1) and friends. > The patch I just committed to main adds a different syscall/KAPI > that allows manipulation of the extended attributes in a Solaris-like > way, which is what NFSv4 calls "named attributes". > Since the ZFS patch in not there yet, you cannot actually use this > new syscall/KAPI (it will just fail with errors like ENOATTR). > > rick > > > > > > > > -- > > -- > > Dennis Clarke > > RISC-V/SPARC/PPC/ARM/CISC > > UNIX and Linux spoken > > From nobody Fri Apr 4 16:04: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 4ZTk2Q1XnWz5s0lg for ; Fri, 04 Apr 2025 16:04:46 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-21.consmr.mail.gq1.yahoo.com (sonic310-21.consmr.mail.gq1.yahoo.com [98.137.69.147]) (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 4ZTk2P6h0rz4LrV for ; Fri, 04 Apr 2025 16:04:45 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=U7lC+nNY; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1743782679; bh=tSagWce7XG0yOi5GHmgQnMNq1iYMYqfLOsOs1Tif6VU=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=U7lC+nNYg2C80k8vC3MGTkwvEHrf6NFIuv2v463wVHscEUdxxlUH9jIK9VhW+lULHKFbwUQ1e+ACvj9XgHoOUQX2xpwCr6tLWVAoJIUtqsChHzsoAUsqsbJvZ2VRZ9T1uceqrGngjhBv8ZLQQXpFuekmbNdauf7mnr6CmRpVZLDe99cQoSgd7x1TIsTGslDqkMcrnLYKsD2jc1r3kB9eUPCGLIEgLkVMBDodBSAxmv+Uf2flzZYynxQoRXcPLQxSwwV6RBFkN2ePwNH3d8ASbTVAhyPpdccpL4WzfAc4P1hSjxmU1ACSCgIDMHOJKUkloBEQGa0FUf6HXfwIcG4Q2A== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1743782679; bh=n6iegbRyheRlEqXnaNld3hqaero+Q/kxnnYc6Z2Stp1=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=nFGf6zK1XqzQFU+2RXJ6pbc4ovwFoJYI1+yBJr8RvCR6Su9HXp9To7dxk519Doy4+KhMkbI95cXYUe3bu/BLPh2k++AZ+KPsdqXZt+piqpwdf0WysLVUrOLIf8hq0DJnekFEJ4cla8qGFaor9cb/RWolhHK+1WzEk6Ett6j3qridkeOgWGa6PLJZH8tXCJyM0y9eDXV19kRxQUzxFzzUopNKQUn0npvtjiuWBqz7y1nHBJDGRYytr7L4AvU6fKCNCZx1blR6YG8M2toO7QVfW9Y/NX2TdFUUp6FpyWEUFWAVpBrDobuhWpYKUKEZ98iZi0Rp8eoNtt02htbBCRrzbQ== X-YMail-OSG: luVKUNIVM1l3zUQg4lOAKel6zpZFMRfzHetIjnBPjUhV7B43hg2xqsxRsnr5K5Y 0_kvTPLMRGS1yZ2J12.QB2zLqKRP09H_U.nb6E8XMH2o9xA4X4tG_5aJOgCuZaDlhuDRllc6cbdC baMMLRiPAlMS0c7aZdkGRPHDW96c_WwGUTZI_xT.NnL3_6nYxNnXbvLdGYOiYPDi6JqjAAS5neho LwaHeKJPNqxQoGea6IMmdp_FnLfSV97DlFeDuyoinr3i0AoXcf5LnYxgX.uxXPP.XPCE7oFHnfLG YBjwuDVWWYcDtMaIJkmzpeaB7FCiSQwhiUUPjJMrGYVSKdOZxAubSqxaa85BJKAOPEduC1D5xpIP ooCI46i_4dvqbTH99IXZTqJjBcDSpr1WtGKXLNTb.zGEZaEtzbBtcaEc394Ba4rkSMCLErESkZfS VOjz24.x54tk63rLImjf3L8L4eDxVxnyWPrWY14jT_2s9OzycJYT.CI7UO2xbfdX9yBBTcXfMXK6 VQlH2wXatD35DA1CqlM_lD9bs1vl0iogrTVOEAXUY4otpzqcdXKgwLffXI8WzmybbzTS.fBMvLyH JR3AOWVcOU9n9UeTHeTuMAOv1gRKq0fTuW3Y71u9TwmnX3DuImvhs70ywK4O83dykoUdT2zgPR8I 3nnhN_8llY5xKq945AZ5K97mK8TL_4UQ3Aic93nGX4B17AOQ851HN8YDnjl.CGF7zzOLCrX4Xe_u J_hVejKME8s3dh2OfswwDHGw4dUDcA_Gi.zQ1KPi.V9XwRsyNASYef4QNwwJI_NlBYv7_s4153BZ TRLL12H6yNxGX6zO0SZnNXQA3XntllqT5syeAapReK.kbtplKE7je0uUqxpKCMk3bVXvvPJZHzsM tVp84m2ONJYlhQkfrYdb2Y.mdtJVPq5ruXxLsnESCLz6ii2yFCtsy4qqHhnfw.0WlfY80fOHVYUI GZJFElxipO.giqWYZBWcN7049lvHwpXWpYDqhRLmX79FNQiHXY5NxpIQ.rA5xUKAsIER3KeNTpdR 4HGCYci86f87kmYfOw09fh7V33FnecJXR4ZZwZk.gsE9MPvDyGzoQC9hOtrWwchGJaAFOzgGlRzV 7BOFo588VDHxZ8ASxhWvG3EyMs3sRirCLla_weJxSqK7GdobNSZly.vPtMY2BJbD8REYUBlbnPyG CoA628ypLM3vrfLCiZcXHywNc6jxKiMX7gd6mJwQP2VD951nAhDA4c.XmZ04AR4a6myuH0NvXeIP DltG4pGutE0B.OlEo19VgChfaG0GXQWXg1Ux_SMNn80uj9f19x.6IOV6_0COIE1rsGqUE32ZcR0o OI6QlAVXa7EwzKz9ptBfc80AjszjMx7COpHdQ.swDRfSTwq.rtkvvyPcjZJo1TwbC_t.oXvON8bq Xxq9Pray9h5mOeqBsOPshcq_Iut5nWjKmZ_.2.kcgmo0X4mlJZcJUHo4_NJMyINZbCCIRjElBhHy 71rkzYeODhomoun1D_rut6QUBWdB5odlq3lUjAut4q1ryGX2Vbg2ENoytmLRbAhgBsilLVIais7b phBPOwx9ztyvtfZXNedWxK7jSPfxSDNfUHDym6gfVl1ZcOf7g3YDnUvcimyeSltxKO9MyiYfo4Dk Sv4wWT7abvoP1EfHkLl6IuG4UwxSFFiYJpiqPx99SxcBl9iFEzt8lOydV7xdrJ1fUWoWBQipIVbw Qg_dR4_kc3W8oceGgatbpMG3pVo9MwMw3F9s1wnwMGbSqP1jiHzB7eeh0jvw6cjnmpezmMaU2NqV p9bqWR.GSayGrovm_9KQ4PwH9KanaKMIMQ6iCNGdlb4DQyGW3smG9umvf10Zv_qMZrBcwwbaEmVq LJAEB9GTecCK9JPCbG5v6Bdz8m9LKHnhaJUchd4ncdNcVfW5f_2cOl8.qChvzlbIjeUVXIygy7bK U8wvywOI9ZlNlmP3h0DKU_Q7jLDxwm5M9Z15GbD3ZuR2FeCRzaDTjS0695JF_jbXP75Z7DsrWwjR eLupbITTUqjn.QPHxaWwnfnm10tdXpAolxxg_hk3TnadsYJYI3XwdW_QQiRwTbXjYVoTifHjRF0b aSG8bBjJF_4qdfclu4v_YVWwja17GIQAgUq.EMlQu.PM3UNPvTz3X4eBSfZGtbKvwBNMGNXSYq4i K7MyU_Jq7eHnGqfbNlIkjinrvkFXgtzs30BlDoobK_2LqQmQZvbUE3LQkT_ydz8fqat1jfiEmsQT qldaogtjqyIVdg1cazflK4N6vhbHPWvZP.VXOPJSbSZx.hCZJeLgsvZeb2X1GNuPqtll_Ibt6hBk M89g- X-Sonic-MF: X-Sonic-ID: 13467484-dec2-4b41-a654-3c240860041b Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Fri, 4 Apr 2025 16:04:39 +0000 Received: by hermes--production-gq1-5c477bf655-cprz5 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 2206a85d83d89daa5fa5fbfbd6fb802f; Fri, 04 Apr 2025 16:04:38 +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.500.181.1.5\)) Subject: FYI: main-armv64-default bulk build times (ampere2) look to have grown significantly with Host OSVERSION: 1500035 instead of prior Host OSVERSION: 1500028 Message-Id: <8E2FBAD3-EF6F-4D99-A340-21F8FD19AE0F@yahoo.com> Date: Fri, 4 Apr 2025 09:04:28 -0700 To: FreeBSD Current , FreeBSD Mailing List X-Mailer: Apple Mail (2.3826.500.181.1.5) References: <8E2FBAD3-EF6F-4D99-A340-21F8FD19AE0F.ref@yahoo.com> X-Spamd-Result: default: False [-4.24 / 15.00]; RBL_SENDERSCORE_REPUT_9(-1.00)[98.137.69.147:from]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; NEURAL_HAM_SHORT(-0.75)[-0.745]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.147:from]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.147:from] X-Rspamd-Queue-Id: 4ZTk2P6h0rz4LrV X-Spamd-Bar: ---- Longest ever prior bulk build of main-arm64-default (HHH:MM:SS): = 171:50:51 (Host OSVERSION: 1500019) On going bulk build: Built 11348 Remaining 23676 (HHH:MM:SS): = 85:57:28 This suggests possibly more like 230+ Hrs for the completed build. Now (0n going bulk build, first such): Host OSVERSION: 1500035 Jail OSVERSION: 1500035 Previously (recent): Host OSVERSION: 1500028 Jail OSVERSION: 1500034 (or before). Longest build time: 163:20:35 That timing is for: = https://pkg-status.freebsd.org/ampere2/build.html?mastername=3Dmain-arm64-= default&build=3Dp02dd5021d6f9_s717adecbbb5 It might be appropriate to monitor: = https://pkg-status.freebsd.org/ampere2/build.html?mastername=3Dmain-arm64-= default&build=3Dp25bf3a3260c7_s680d34896c3 Note: https://pkg-status.freebsd.org/builds?type=3Dpackage&all=3D1 can = be sorted to find the 171:50:51 that I list. I''ll note that it was for: Host OSVERSION: 1500019 Jail OSVERSION: 1500023 =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Apr 4 16:06: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 4ZTk4417pSz5s0m6 for ; Fri, 04 Apr 2025 16:06: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 4ZTk431x2nz4NqD for ; Fri, 04 Apr 2025 16:06:11 +0000 (UTC) (envelope-from dclarke@blastwave.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=blastwave.org header.s=default header.b=VreFBclg; 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 534G63Zs003938 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Fri, 4 Apr 2025 12:06:05 -0400 (EDT) (envelope-from dclarke@blastwave.org) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=blastwave.org; s=default; t=1743782765; bh=TeOvobjwogE9x9+mAJ5zhNbPn1cFOIQmSflH/Pe9Py4=; h=Date:Subject:To:References:From:In-Reply-To; b=VreFBclglSsQVb1zXoVf+MX6GbHo5uRmstSl+G/4BLMs0GQP2HKPAndn4FqtGO6Kf NyMxLmrzKZOQz2mDUPtjGUj8wZh/EDB1HCQaBWik3BFih0mB/Yylsvnc7T7eoklb9l fFedkFsN36cd31EEAW2bjxk9IOw88dQsQmxEf488OxSnf8ygTbhqfvHyX/t+Rf5819 0j3BamQVkQwdRq2jXsP9O7GMfebf72CpWmNXzZR3gjo50IUZBUqkDtXBkfTrU0l0Ma E96ovE9g7ube0tG3gDxSJ9rxSeW9tYYEUSxyK3p4ESgDzsaGXTc5J1S0WphEPB1h6B asPDBB6eHMkFQ== Message-ID: <613d4907-6837-4cdb-abc5-86e53a6cce14@blastwave.org> Date: Fri, 4 Apr 2025 12:06:03 -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: Heads Up: commit 2ec2ba7e232d just hit main 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: 534G63Zs003938 X-oetec-MailScanner: Found to be clean X-oetec-MailScanner-From: dclarke@blastwave.org X-Spam-Status: No X-Spamd-Result: default: False [-4.40 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.93)[-0.932]; NEURAL_HAM_MEDIUM(-0.77)[-0.771]; 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:c]; RCVD_IN_DNSWL_MED(-0.20)[108.160.241.186:from]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; HAS_ORG_HEADER(0.00)[]; ASN(0.00)[asn:812, ipnet:108.160.240.0/20, country:CA]; RCVD_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_ONE(0.00)[1]; 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: 4ZTk431x2nz4NqD X-Spamd-Bar: ---- On 4/4/25 10:25, Rick Macklem wrote: > On Fri, Apr 4, 2025 at 6:37 AM Rick Macklem wrote: >> >> On Fri, Apr 4, 2025 at 1:48 AM Dennis Clarke wrote: >>> . . . >>> well ooops .... what was the idea here again ?? >> Well, this has nothing to do with my recent commit. >> Thus.... ooops. >> ZFS has always supported NFSv4 ACLs (and not POSIX draft ACLs) >> on FreeBSD. (I actually am planning on a ZFS patch to add POSIX >> draft ACL support, but I haven't even started to work on it. I do have >> an IETF draft that adds POSIX draft ACL support to NFSv4.2.) >> >> If you look at the setfacl man page, it shows you how to set NFSv4 >> ACLs. > Oh, and to clarify it, ACLs are stored as "system" extended attributes, > which this new syscall/KAPI does not access and, in general, anything > else can be stored in extended attributes as well. > So no easy way for a user/sysadmin to see what the big "Heads Up" did. Dennis From nobody Fri Apr 4 17:50: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 4ZTmNy5Njsz5s99L for ; Fri, 04 Apr 2025 17:50:58 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (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 4ZTmNy05GHz3TZh for ; Fri, 04 Apr 2025 17:50:58 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=hardenedbsd.org header.s=google header.b=Yrw00AqA; dmarc=none; spf=pass (mx1.freebsd.org: domain of shawn.webb@hardenedbsd.org designates 2607:f8b0:4864:20::d35 as permitted sender) smtp.mailfrom=shawn.webb@hardenedbsd.org Received: by mail-io1-xd35.google.com with SMTP id ca18e2360f4ac-85ea482e3adso103141239f.0 for ; Fri, 04 Apr 2025 10:50:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd.org; s=google; t=1743789057; x=1744393857; 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=ZtzDTTtowor4NFAWo0P42msdsLNyrtAq9HAnB8lYkRo=; b=Yrw00AqA/1AQiuDrD5TNumr4JhgrYpV0omZccIybSjQNe9S1b/Z1DO+kuDcxPKJfvB qL8xgYmqrOUw1zwJvlQMvPCgavG0VFfczfciuzSw5RK0jbOA7SvYuqof8LYaW0gF5pLO 1MlpAdTOGYBNpS/0E9EZ2unl/kJGsBfFvZjwpYY8U7Kw0YimjJt1duINiCkPM9xzZsER msTJjN5VEMK4+phafkTgybLR2vmkqY1mySH6aZadDIJw/27reYNsK2+i3LU1EiHQeWl3 MpURb9F1JukXiYeK6FU9DOi/E7s+OA/VJ9iB9sP7keYJPvuegc8yBvN80hRUZsYZ5bWN 9Y+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743789057; x=1744393857; 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=ZtzDTTtowor4NFAWo0P42msdsLNyrtAq9HAnB8lYkRo=; b=afxtTWHei6+YqYIbQ0DZad0FK9dugEUbpR60y1zhVDd8iJNCnsapJKXWLRjY0LlNqi 62QX84BZrJKFKjKgVsPj8ifHoVYlx2zwlVmPxhgiJg7Sq+gtHA93COOtDrpYVNFmc9vD NQJNqEIzYQdUHzd7nV1Ui68a65lKhMHLNDswAOlFBnjI8xBVh2PR6s0ColarWCcn/dzy xb65em1EBxf4g7jGlu/pKFOKs1tz8M3bKXyIUH50CP56AZqYR6iSHMuvc6HR17Z4Wo0B +h9VZ3iiW14taTQjVOcN/a4oHOEP2a+gwVxMOvC0HL4T5uWMTlWTS3GroeTcGuWhT7Vx 1qiQ== X-Gm-Message-State: AOJu0YznOfxKscJCMwUCrQpUc2b/JztMaunqzYr3oV68qKAvskS3QI/y PGp1z5d1XJlpYzSYmKHRo4pAYKNETuIVxiisxC3clxUeW3e+zEoEDFdhfklq7uFGU/4APDh6S6/ ZG0g= X-Gm-Gg: ASbGncsxf5UAGR8fXJJyaC+zJfe54iMXphFvHFNpvL42a+GGcQ4/akES4h0uwZVKQtj imnrg574jDrwi/uaeLtbXvTsyifxfU+R3puweJOiNBF1tLnOkuKkhtDGuaGMINQn4UQvLEoDaz/ HzT43xRQfjNZtashLjIBx3I9TsQjkTSJOKBI8Fkdtwr3cEsy+4NkQdOxrcFpy0Qc9RLt0nJPrJZ H+IeNfzF7ddiNEhMfumuMuKu0WXuTYBSEhFKP5OLo7+W+GLhkrMPCASnb7DQUWLfAgs35MVEdyP 9nQAZD1vAYXXwb+j/XuiJ8EX6MU= X-Google-Smtp-Source: AGHT+IGLnxOc72ZfBwxbsHwkk3RZFYRnIWkqEp6KEsG+5xDdpwLxeuVBFSnyo7+4Ye7W6P+ILR5a/w== X-Received: by 2002:a05:6e02:12cd:b0:3d6:c2ff:eee2 with SMTP id e9e14a558f8ab-3d6dcb7c764mr103787345ab.6.1743789056855; Fri, 04 Apr 2025 10:50:56 -0700 (PDT) Received: from mutt-hbsd ([2001:470:4001:1::95]) by smtp.gmail.com with ESMTPSA id e9e14a558f8ab-3d6de95e87asm9262795ab.44.2025.04.04.10.50.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 04 Apr 2025 10:50:56 -0700 (PDT) Date: Fri, 4 Apr 2025 17:50:55 +0000 From: Shawn Webb To: Rick Macklem Cc: FreeBSD CURRENT Subject: Re: Heads Up: commit 2ec2ba7e232d just hit main 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="f3x6klg4tulymelo" Content-Disposition: inline In-Reply-To: X-Spamd-Result: default: False [-5.10 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; MID_RHS_NOT_FQDN(0.50)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; R_DKIM_ALLOW(-0.20)[hardenedbsd.org:s=google]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; RCPT_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[hardenedbsd.org:+]; ARC_NA(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; DMARC_NA(0.00)[hardenedbsd.org]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MIME_TRACE(0.00)[0:+,1:+,2:~]; 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::d35:from] X-Rspamd-Queue-Id: 4ZTmNy05GHz3TZh X-Spamd-Bar: ----- --f3x6klg4tulymelo Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: Heads Up: commit 2ec2ba7e232d just hit main MIME-Version: 1.0 On Thu, Apr 03, 2025 at 06:12:59PM -0700, Rick Macklem wrote: > On Thu, Apr 3, 2025 at 4:52=E2=80=AFPM Shawn Webb wrote: > > > > On Wed, Apr 02, 2025 at 01:51:26PM -0700, Rick Macklem wrote: > > > The commit 2ec2ba7e232d just hit main. I do not think it will > > > cause problems, but it is fairly large. > > > > > > Man page updates will be done as separate commits. > > > > > > Hopefully this will not cause grief, rick > > > > Hey Rick, > > > > The patch review test plan mentions a patch to ZFS itself to support > > named attributes. Is that patch available somewhere? > The ZFS patch is currently in phabricator as D49654. > Feel free to review it. >=20 > It can also be found at: > https://people.freebsd.org/~rmacklem/zfs-xattr.patch > (this is a smaller diff which can be applied to an up-to-date main src > tree easily) Hey Rick, I applied that zfs patch, but trying pathconf(2) on a file on a ZFS dataset with xattr=3Don (which seems to be the default) returns 0. Am I doing something wrong? =3D=3D=3D=3D BEGIN LOG =3D=3D=3D=3D hbsd-current-01[shawn]:/home/shawn/tmp $ ./xattrtest xattrtest xattrtest: Named attributes not enabled: No error: 0 hbsd-current-01[shawn]:/home/shawn/tmp (1) $ zfs list /usr/home/shawn NAME USED AVAIL REFER MOUNTPOINT rpool/usr/home 10.4G 71.4G 9.85G /usr/home hbsd-current-01[shawn]:/home/shawn/tmp $ zfs get xattr rpool/usr/home NAME PROPERTY VALUE SOURCE rpool/usr/home xattr on default =3D=3D=3D=3D END LOG =3D=3D=3D=3D That xattrtest application is yours from: https://people.freebsd.org/~rmacklem/xattrtest.c Thanks, --=20 Shawn Webb Cofounder / Security Engineer HardenedBSD Signal Username: shawn_webb.74 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 --f3x6klg4tulymelo Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEA6TL67gupaZ9nzhT/y5nonf44foFAmfwG/kACgkQ/y5nonf4 4fo/Kg/9G/DLXnCxy8z7DgqPohKe2+MM8aIPQZOVC4ftCrW/AP/Ehnx2FxYrwQ6t edAshtdUhOHtKBByEvhDjNxv/C2xBb6hna5opHTOcam5oZPSbnGwUXzZBVxGqZsM UAKNdf2mgq0HZBjYp67qA0u5UbjThZSSc7cxJnTAi8yZb0++X/kzvBXIN9m2rqNH 7zyvHolkAZv9EhBU4wAO08gNb40HvvzX9eAWleRFjVdBakPOLPaYo+8bBEDi+6pA xNgsiUUUm4sqd5ukk/4Lth/19ECsob70V1PH0J7QqZvGcyW3X+Y/hx7q/niOl+Ec xc6PPLMGLh5TNAR2I0c0hbd9DYi9HjHGFB5/6mhRgGar/rxfcDlYA9nqJlLuIJK5 nKmK5/1nqPo6vzS8R28uBfEm3a3c/mAwKo15IidAGTlCkthUeLeQok7BHFZdkpT1 hysX9eytg6Ehc+HIUjtEDRHLHMjka2/QcCEBUFJdo6kohJXnBgKsmFraW/KklBHh a0SnUECV7PRVgaojbI8yIXXUXBSXM7pcpLJ0P0OYnzluXMTN+JJxBRDmK1ORpGyk C6GqX8B1GxgQQj50QQ0Y6j9riDFgsyVV8gKuh/nfm7od00a4UZ+OjIFDO+9xQlxV WN+wDKoJHdzUM9Gwd9JjLy4gB6sx5J1sSAsLFUq8nSm8ea9zjeQ= =edpD -----END PGP SIGNATURE----- --f3x6klg4tulymelo-- From nobody Sat Apr 5 00:40:21 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 4ZTxTZ63wtz5sgrw for ; Sat, 05 Apr 2025 00:40: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 4ZTxTZ254Rz3jBT for ; Sat, 05 Apr 2025 00:40:34 +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-5e6ff035e9aso5004164a12.0 for ; Fri, 04 Apr 2025 17:40:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1743813633; x=1744418433; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=FxrDhVEw40E1CmHSmoFo4P5AZ4cHLRTJ4HV25EGiiLE=; b=gT41Z4FRg7vpYhsL5FF+SxtQDUJ3j496PvrIilpz6CyLfkwy9g/tV610ugIeV0h6Hg pdkdVEhAGi6ZlIoEpVVTamnnvwiaf6yztNDsx8Uiwenk92abYF6G+mSAMw8M71jFoknC 6oMTDH6ewHlONnzwU/s42kvYubNxC5bo0ovBsChpPAZin4wSRJCc+VBuAfadpUxqskmg ld9jgkWJqrRyM/i2SizgCqUF0hd/8UGh5kKG00emz/XvugirM56uRTq8MPyD3IAU8f7d BBo1mlgop4wouPax3o8lNe9yaMIRtlORlTE/EAvxTWzjT1u7K1X3E9sfImHLKXLwJa9O Ux0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743813633; x=1744418433; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=FxrDhVEw40E1CmHSmoFo4P5AZ4cHLRTJ4HV25EGiiLE=; b=bg+7gucCnnWhdZMFMdWGzPgDEyr4z90muVm07sWlfQoT4epMNlJVasMEO1HmbIsFIu 5p60u1D1IdJXDSrPwAnpuEThInTTNLtkZk29k4dyDl8cHOCa1+5PmZOYO5rWBC7KMIVY 5lo3wtSr6iL87cDXTHVcnRGvKfuWhnhe2rInMKG9z7HRzTUeGxcmkza0oiI0GK41zYIx 2evGYMrX+mpy9MOzu7/YLJFiVyS3NyqnXRGRHaQDVZRkRE1sxlGfjIAcXNIrOA0duDQe T2t79Oxlr/+OM+H7sHXMALwE4Y1fc9nIGb9PBlJo81JliwjluZYyJd81QO7EZTorHqu1 ND1A== X-Gm-Message-State: AOJu0Yxm8iWs0z9Cva8JlDv9uwy1HZh5AnjzdyEQt/p4v+LoF62zSPEW iTEj5NQmup/223Mrj8AhbEo91XAhkPLuBLsQEu91Gdfe76rd2V5KMY58C10t4lYW6L4UOSfs1sj 7t//IxMoNSdnV9bOdVWE8vXPsUQ== X-Gm-Gg: ASbGncuQDNOEr5qLDNilG6Rj0nNcCAdxtexI8daEebwnfj/rDYaErczPhrr5hP2uZJd VAPwoVm7TxlnmkL4rWDOgVlZkTKXM+Au0yRhV3EWWXHRoKLDbvcAmk3RL1BimZULEymG34LutZc Q1FkCHXPhDfmcMIyjf2YTqx3HSlWiZfU76X5pdM2x2lgX3HsNNmnihTvEOaQ== X-Google-Smtp-Source: AGHT+IERYkPCsbkL35IBhhnG5mz/dqnosxBHphaM5k5HbzNcru+A11Z5dJIR7XxEYSlCUzSmvkAJJ/GLu7N0wpobPUw= X-Received: by 2002:a05:6402:5194:b0:5ed:d761:db9d with SMTP id 4fb4d7f45d1cf-5f0b470402emr3804096a12.31.1743813632580; Fri, 04 Apr 2025 17:40: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: Fri, 4 Apr 2025 17:40:21 -0700 X-Gm-Features: ATxdqUGTCfRnCkKvJmGbtxi5E56o8IIm0nLpul7PHdMBox0fMbWU6hIShlZ5GXg Message-ID: Subject: Re: Heads Up: commit 2ec2ba7e232d just hit main To: Shawn Webb Cc: FreeBSD CURRENT Content-Type: multipart/mixed; boundary="0000000000002016e30631fd405d" 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: 4ZTxTZ254Rz3jBT X-Spamd-Bar: ---- --0000000000002016e30631fd405d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Apr 4, 2025 at 10:50=E2=80=AFAM Shawn Webb wrote: > > On Thu, Apr 03, 2025 at 06:12:59PM -0700, Rick Macklem wrote: > > On Thu, Apr 3, 2025 at 4:52=E2=80=AFPM Shawn Webb wrote: > > > > > > On Wed, Apr 02, 2025 at 01:51:26PM -0700, Rick Macklem wrote: > > > > The commit 2ec2ba7e232d just hit main. I do not think it will > > > > cause problems, but it is fairly large. > > > > > > > > Man page updates will be done as separate commits. > > > > > > > > Hopefully this will not cause grief, rick > > > > > > Hey Rick, > > > > > > The patch review test plan mentions a patch to ZFS itself to support > > > named attributes. Is that patch available somewhere? > > The ZFS patch is currently in phabricator as D49654. > > Feel free to review it. > > > > It can also be found at: > > https://people.freebsd.org/~rmacklem/zfs-xattr.patch > > (this is a smaller diff which can be applied to an up-to-date main src > > tree easily) > > Hey Rick, > > I applied that zfs patch, but trying pathconf(2) on a file on a ZFS > dataset with xattr=3Don (which seems to be the default) returns 0. Am I > doing something wrong? > > =3D=3D=3D=3D BEGIN LOG =3D=3D=3D=3D > hbsd-current-01[shawn]:/home/shawn/tmp $ ./xattrtest xattrtest > xattrtest: Named attributes not enabled: No error: 0 > hbsd-current-01[shawn]:/home/shawn/tmp (1) $ zfs list /usr/home/shawn > NAME USED AVAIL REFER MOUNTPOINT > rpool/usr/home 10.4G 71.4G 9.85G /usr/home > hbsd-current-01[shawn]:/home/shawn/tmp $ zfs get xattr rpool/usr/home > NAME PROPERTY VALUE SOURCE > rpool/usr/home xattr on default > =3D=3D=3D=3D END LOG =3D=3D=3D=3D > > That xattrtest application is yours from: > https://people.freebsd.org/~rmacklem/xattrtest.c No idea. It works for me. You used up-to-date kernel sources? (Check that VIRF_NAMEDATTR is defined in sys/sys/vnode.h.) Oh, and one more thing to check. zfs_xattr_compat needs to be non-zero. (It's found in sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vnops_os.c. It's initialized to 1 and I don't see anything that sets it to 0?) The only thing I can think if is, if you changed xattr to on, you need to reboot (or at least remount) to get it to take effect. (Maybe try setting it to "dir" and then reboot/remount. Maybe there is a difference between "on" and "dir"?) Or, did you build zfs.ko some other way than as part of a kernel build? (It needs the patched .h files in the kernel sources, not something in /usr/include/sys that has not yet been updated.) All the ZFS changes are #ifdef'd, since OpenZFS requires the sources build for older kernels. (Basically #ifdef'd on that VIRF_NAMEDATTR mention= ed above.) It does remind me that I need to try a build of zfs.ko by doing a "make" in the module directory. You can try the attached trivial patch and see if it spits out "pathconf re= t=3D1" on the console. rick > > Thanks, > > -- > Shawn Webb > Cofounder / Security Engineer > HardenedBSD > > Signal Username: shawn_webb.74 > 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 --0000000000002016e30631fd405d Content-Type: application/octet-stream; name="pathconf-zfs.patch" Content-Disposition: attachment; filename="pathconf-zfs.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_m93hlptp0 LS0tIHN5cy9jb250cmliL29wZW56ZnMvbW9kdWxlL29zL2ZyZWVic2QvemZzL3pmc192bm9wc19v cy5jLnh4eAkyMDI1LTA0LTA0IDE3OjM1OjM0LjUzNjg4NDAwMCAtMDcwMAorKysgc3lzL2NvbnRy aWIvb3Blbnpmcy9tb2R1bGUvb3MvZnJlZWJzZC96ZnMvemZzX3Zub3BzX29zLmMJMjAyNS0wNC0w NCAxNzoyODo1NS41MTE0NzIwMDAgLTA3MDAKQEAgLTUzMzMsNiArNTMzMyw3IEBAIHpmc19mcmVl YnNkX3BhdGhjb25mKHN0cnVjdCB2b3BfcGF0aGNvbmZfYXJncyAqYXApCiAJCQkqYXAtPmFfcmV0 dmFsID0gMTsKIAkJZWxzZQogCQkJKmFwLT5hX3JldHZhbCA9IDA7CitwcmludGYoInBhdGhjb25m IHJldD0lbGRcbiIsICphcC0+YV9yZXR2YWwpOwogCQlNTlRfSVVOTE9DSyhhcC0+YV92cC0+dl9t b3VudCk7CiAJCXJldHVybiAoMCk7CiAjZW5kaWYK --0000000000002016e30631fd405d-- From nobody Sat Apr 5 01:04: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 4ZTy196NvYz5sjGh for ; Sat, 05 Apr 2025 01:04:29 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-il1-x130.google.com (mail-il1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (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 4ZTy186yR1z3pZV for ; Sat, 05 Apr 2025 01:04:28 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=hardenedbsd.org header.s=google header.b=dzpAbqU3; dmarc=none; spf=pass (mx1.freebsd.org: domain of shawn.webb@hardenedbsd.org designates 2607:f8b0:4864:20::130 as permitted sender) smtp.mailfrom=shawn.webb@hardenedbsd.org Received: by mail-il1-x130.google.com with SMTP id e9e14a558f8ab-3d45503af24so23781345ab.2 for ; Fri, 04 Apr 2025 18:04:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd.org; s=google; t=1743815067; x=1744419867; 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=wIbzQVy9s/iXHCemJ7tXHEy2j//iu11sNi4izBiHS5Y=; b=dzpAbqU3d+1/Yah+qm+A/70bSCwg2ymUKlqMSQG+UoWUA7a1kiuw/VIOfDHwzdwU0A xuKIeDmE/0pZSxb38bL6RGcw6j/KofAJ06d3NHjGHZxdreAT5XGf8X1LsPkGOirITVvc tOE3d8UQBEN3ODqf8PlL0bq+ocls6XGSIZIMqgJEUFF9MPTzCYINDHFnmgai3443XYaz wYnahiVZJpXua5uFVFRKb4LF6RD94GUlo9AUTigUyjZeDfQnmfyKzMUzDZG34N9PSv+r 318aPChBVBWXgT5OYNB0Lf61HYpSPVL/sgr5Rbz16B6E1dts8MEUAem1/JoOQX3eCi6b FD2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743815067; x=1744419867; 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=wIbzQVy9s/iXHCemJ7tXHEy2j//iu11sNi4izBiHS5Y=; b=KOrP2BUg0cYwtfLYXo8g+rHsYJ4420a7ulbHw0vJ350+sjOJBZlShipFWSPxtEQarW orYLywDr2gC/PHkXj38xpiuDr7pDB2Eixo7gwipMzVntVET39o5PD11RTMx7MHykqRrF QBhno669LmrQa7CAA8+Uj6RinnZXx4qps/A4jlRBZVbYYoLoDHOxSKH8lVwIUwEVydWD c5apDMdGSqt/OyZo34SkeLt1eJUZHxqgzIaZf98LM7d2uzW4fFVH1q8tI/6T0SwJ19km FGhUERpzkNEQfy9KRQThSeDvx0tGVdB514j0Ql28j1tD3xWHQ3k0jYqcphHhZCXR4GNo 09mw== X-Gm-Message-State: AOJu0YyrfrSLXjLAI2UEvOX49dsIFA8gxn98VsGpjaY6HG8WitRV5CgH 2LQa22B2YCDPwdnVqPrO/k4cmFF3dOfIFHXNUk1avdl1942Dowwm9m+K3x8r6wPpQ4iike0RbAo 3OEQ= X-Gm-Gg: ASbGncvfgYfiAPc7c4LBMFQ3Tc1xRRkedx9E6XJHUa46K8xIT0okZ+xaNaUXXcTmviK J//APSalBr4vUSePWJxrhsqsUozxF4mvqOMxoClvVtgw60SfFEyATsuh1F0z87y/0qbuZSH/O6Z sPaWj7Utbbc9N3fn64R6jk8zewFcpsbs1pK+lXbfixlTYHwm9ReNU51syy5byH/EdwOlMN0U2B7 OiF6weZULvMkLiqUuKVEdILB8mJpOKh1aqve/pYwitpWDsIt2mWItLurA91mT8e+oSGON01qFj7 1PAxPutJ+hdB979NQZm/d6tYkrM= X-Google-Smtp-Source: AGHT+IGLM44Ir9rQIkYBlE02nrAHTA2wycoeMS6eVX9bDVDYHAd/JmGQqM+J3ooVTGJPgSgSml+xCA== X-Received: by 2002:a92:c24f:0:b0:3d3:dcfd:2768 with SMTP id e9e14a558f8ab-3d6e3eea7d0mr66030135ab.4.1743815067455; Fri, 04 Apr 2025 18:04:27 -0700 (PDT) Received: from mutt-hbsd ([2001:470:4001:1::95]) by smtp.gmail.com with ESMTPSA id e9e14a558f8ab-3d6de972df9sm10878655ab.66.2025.04.04.18.04.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 04 Apr 2025 18:04:26 -0700 (PDT) Date: Sat, 5 Apr 2025 01:04:25 +0000 From: Shawn Webb To: Rick Macklem Cc: FreeBSD CURRENT Subject: Re: Heads Up: commit 2ec2ba7e232d just hit main Message-ID: <2rq3bpvhclcipvgg3mo4gml7ysuzbvt6rfnzkprceumzeaeh4b@casrpprm6mgt> 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="yq5cf7pzbpfqy27c" Content-Disposition: inline In-Reply-To: X-Spamd-Result: default: False [-4.43 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MID_RHS_NOT_FQDN(0.50)[]; NEURAL_HAM_SHORT(-0.33)[-0.326]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; R_DKIM_ALLOW(-0.20)[hardenedbsd.org:s=google]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; RCPT_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[hardenedbsd.org:+]; ARC_NA(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; DMARC_NA(0.00)[hardenedbsd.org]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MIME_TRACE(0.00)[0:+,1:+,2:~]; 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::130:from] X-Rspamd-Queue-Id: 4ZTy186yR1z3pZV X-Spamd-Bar: ---- --yq5cf7pzbpfqy27c Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: Heads Up: commit 2ec2ba7e232d just hit main MIME-Version: 1.0 On Fri, Apr 04, 2025 at 05:40:21PM -0700, Rick Macklem wrote: > On Fri, Apr 4, 2025 at 10:50=E2=80=AFAM Shawn Webb wrote: > > > > On Thu, Apr 03, 2025 at 06:12:59PM -0700, Rick Macklem wrote: > > > On Thu, Apr 3, 2025 at 4:52=E2=80=AFPM Shawn Webb wrote: > > > > > > > > On Wed, Apr 02, 2025 at 01:51:26PM -0700, Rick Macklem wrote: > > > > > The commit 2ec2ba7e232d just hit main. I do not think it will > > > > > cause problems, but it is fairly large. > > > > > > > > > > Man page updates will be done as separate commits. > > > > > > > > > > Hopefully this will not cause grief, rick > > > > > > > > Hey Rick, > > > > > > > > The patch review test plan mentions a patch to ZFS itself to support > > > > named attributes. Is that patch available somewhere? > > > The ZFS patch is currently in phabricator as D49654. > > > Feel free to review it. > > > > > > It can also be found at: > > > https://people.freebsd.org/~rmacklem/zfs-xattr.patch > > > (this is a smaller diff which can be applied to an up-to-date main src > > > tree easily) > > > > Hey Rick, > > > > I applied that zfs patch, but trying pathconf(2) on a file on a ZFS > > dataset with xattr=3Don (which seems to be the default) returns 0. Am I > > doing something wrong? > > > > =3D=3D=3D=3D BEGIN LOG =3D=3D=3D=3D > > hbsd-current-01[shawn]:/home/shawn/tmp $ ./xattrtest xattrtest > > xattrtest: Named attributes not enabled: No error: 0 > > hbsd-current-01[shawn]:/home/shawn/tmp (1) $ zfs list /usr/home/shawn > > NAME USED AVAIL REFER MOUNTPOINT > > rpool/usr/home 10.4G 71.4G 9.85G /usr/home > > hbsd-current-01[shawn]:/home/shawn/tmp $ zfs get xattr rpool/usr/home > > NAME PROPERTY VALUE SOURCE > > rpool/usr/home xattr on default > > =3D=3D=3D=3D END LOG =3D=3D=3D=3D > > > > That xattrtest application is yours from: > > https://people.freebsd.org/~rmacklem/xattrtest.c > No idea. It works for me. You used up-to-date kernel sources? > (Check that VIRF_NAMEDATTR is defined in sys/sys/vnode.h.) > Oh, and one more thing to check. zfs_xattr_compat needs to be non-zero. > (It's found in sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vnops_os.c. > It's initialized to 1 and I don't see anything that sets it to 0?) It is indeed set to 1. >=20 > The only thing I can think if is, if you changed xattr to on, you need to > reboot (or at least remount) to get it to take effect. > (Maybe try setting it to "dir" and then reboot/remount. Maybe there is > a difference between "on" and "dir"?) Yeah, tried rebooting and still no go. Note that xattr defaults to "on" in FreeBSD by default. My src tree is synced up to FreeBSD commit 7e70d94acd68b3ac6b45f49d4ab7a0f7867c3ea7. I brought in the ZFS patch you linked to. >=20 > Or, did you build zfs.ko some other way than as part of a kernel build? > (It needs the patched .h files in the kernel sources, not something in > /usr/include/sys > that has not yet been updated.) > All the ZFS changes are #ifdef'd, since OpenZFS requires the sources > build for older kernels. (Basically #ifdef'd on that VIRF_NAMEDATTR menti= oned > above.) Perhaps I need to do a clean build. I'll try that and report back. >=20 > It does remind me that I need to try a build of zfs.ko by doing a "make" = in > the module directory. >=20 > You can try the attached trivial patch and see if it spits out "pathconf = ret=3D1" > on the console. I'll try that after a clean rebuild of the kernel. Thanks, --=20 Shawn Webb Cofounder / Security Engineer HardenedBSD Signal Username: shawn_webb.74 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 --yq5cf7pzbpfqy27c Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEA6TL67gupaZ9nzhT/y5nonf44foFAmfwgZMACgkQ/y5nonf4 4fqXzw//c+q0dKh9EREqE5H1OWhaOG2iwjeIjWSVrlS25PTPEOYQQeFNK2MeCH+9 qSKgmdI/IyPZ+XUfgRmuRWBWI9lQgh3n+Hhmj4CSvlPHgbC2Z3hqbeb/Auuie6C7 QFkTzrN7SAxOUtItGWTiLyHPMCo/fvqNoP2llbMAWevkg8zWhe3xspsgYQPlLfkg E7T47i/VVj9YQ85l1WU0s5eZ+D6GGbB0j0i3nZP/S+ffBItUvHLtgGrZpQJp8nAg YcIbl0QPMjDQzCSGNIu2uq0CZxa9UIoS8gr8WO0VQrn3KQWGnicH/cXf5u1fGGKG AvR6RG86Wl+ardvbeA+OZLakskR5ZySrCnUC1FZ1yjFXIw3ixU38QXW+VX7W7Gpx sKtYgmuIAvLnFZ/iR1M3kUuRUPzit4w6OHxT3bB3h2t0jZDWJCsKR1/ZKssWUPtH zx/zWVVhLL49qpb1Jc03lnV3qRmLCGCnHOWOqdUJd35qEx2VaoGbGuFMYPbQ2SIi CaSN7dkxv8TPDh9Q0rp0s+bZCdZFeIUU9ECIq5QvcLWKIHX3boStCEfhKvg1oApL 0jYyFMGejL0EkjTQydN4qfZhDXTVcZOcymlcOAfyzCJapNEDUjOvHKafYF3S/iFO PpTCv94nqkAracms3UdP5GPqcuWlRKfr8ZFl2ACDAAa7VdrlJZQ= =P6/T -----END PGP SIGNATURE----- --yq5cf7pzbpfqy27c-- From nobody Sat Apr 5 01:27:17 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 4ZTyWY3nt1z5sknZ for ; Sat, 05 Apr 2025 01:27:21 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (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 4ZTyWX579vz3sZy for ; Sat, 05 Apr 2025 01:27:20 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=hardenedbsd.org header.s=google header.b=VocQiek7; dmarc=none; spf=pass (mx1.freebsd.org: domain of shawn.webb@hardenedbsd.org designates 2607:f8b0:4864:20::d2a as permitted sender) smtp.mailfrom=shawn.webb@hardenedbsd.org Received: by mail-io1-xd2a.google.com with SMTP id ca18e2360f4ac-85e14ce87ceso83289739f.1 for ; Fri, 04 Apr 2025 18:27:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd.org; s=google; t=1743816439; x=1744421239; 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=lbcVDVcDJ0olPSSwil0YvMr45X9chIswxvLaO/Mu65A=; b=VocQiek7KxOz1sDp/Is8Y+r+jZMLIYFb9f/4Bp8uDqfRv1P5WDD1UsnFvuQ3jSSwMq dZgaF27/5UzcLdefhZZqOluTN9DB2ZM1kcnSKaO5qzP3TEiYKA9gJDpPqVgb7rHNTXff 9IcUeE9UjJdsfjc7LtZP4JUN52ZfMEfuS8WXsx94wY35OXHt2TBWILID1rzT+aVHvYSp NowK/qvb76OEc018rag1Z+M72uFathEInl7CzKBGpKsozSIj9f2Dr/TvaXNv2EKYSj24 H+8FBoitKf8mg5gO2rySq4d+CAhI4IlZXgOVCbCY8xMG5V2Hld9YTZygm56W1vPU6ptn TTxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743816439; x=1744421239; 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=lbcVDVcDJ0olPSSwil0YvMr45X9chIswxvLaO/Mu65A=; b=Q5KIWnSum/MI69X47/AeoMCmlysgDGvoeFCw58dJ9GSAPHs5toorGjVbQpAyJ+Iji9 2ftGQTl1cts9UHzR60KLviU1dQTwzfaTLvpJIYai06DWas/n1kE+0/EzQRoKZIXqHyNP 4Kk68x5AwSZsOh4Tm11qXGw+sAVlgMOJJDH1mcTLKzLW16Aw/YZtLc/Q+maSE/XpW6ZA KaGNLLk3xBoLogFKf1Uw76kWTswTKwcvQ8AjPBKDtGsCkIEbLya1ukOtcLaJaQ8JHCPt r+60V3YZsZiG3H/J+X8dAuROccrFI0x7NCQ9a8cnvcvzahTjlvAoRRD+P9Z7Ox3jPNnp J9QQ== X-Gm-Message-State: AOJu0Yw/wZI12inEkfrP4jK3C3pGbiyJoifFh5slTlfNb1BUirhdSo4v HpPR2/kASBqSZkPHx1QlC1bY/jeYi/R7R+MEdspDwFcAgwaLxXci0Seyqjz7u0U= X-Gm-Gg: ASbGncuNU6Qz2x8krr6GNDgZnk0C4vi8cLm9xPg9Zge6a7myrp6Cp4pjHGMRo1jcuDb IwDxoCxzPDHkE89pAS9INa728URISDBosA5I/W0JGvLrYZGvHvQeKECZXRgmMCSpRZGjhZJPyjc A+KG/2jlUlDL/UN3PTDPK/zG0FhWWKG0OLjiUND0J+9ETnQN7DbNBZxEEbTuTqoKtx0Bfh0ZP4N IdH0EXjSw2ekJ6x9BCAYrJ2BrfyQNu5A7M9SYfNzFew2cEzOzaWTLbvU1+AhxYWFRKP/JKixoxA r8NTg3TEc4z4UREYHaW6NUYQsWM= X-Google-Smtp-Source: AGHT+IH0upEJgJQ50YjjuAfmjCUCCv3iXAkaeGyiL9C3hHdu1vzDdSDwp+8PK/xUpHqAZwvWAoqVlg== X-Received: by 2002:a05:6602:3793:b0:85b:5869:b5f with SMTP id ca18e2360f4ac-8611b2321a1mr434867839f.5.1743816439297; Fri, 04 Apr 2025 18:27:19 -0700 (PDT) Received: from mutt-hbsd ([2001:470:4001:1::95]) by smtp.gmail.com with ESMTPSA id ca18e2360f4ac-8611125efc2sm84872139f.6.2025.04.04.18.27.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 04 Apr 2025 18:27:18 -0700 (PDT) Date: Sat, 5 Apr 2025 01:27:17 +0000 From: Shawn Webb To: Rick Macklem Cc: FreeBSD CURRENT Subject: Re: Heads Up: commit 2ec2ba7e232d just hit main 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: <2rq3bpvhclcipvgg3mo4gml7ysuzbvt6rfnzkprceumzeaeh4b@casrpprm6mgt> 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="rk5whyzphwrh6biv" Content-Disposition: inline In-Reply-To: <2rq3bpvhclcipvgg3mo4gml7ysuzbvt6rfnzkprceumzeaeh4b@casrpprm6mgt> X-Spamd-Result: default: False [-4.91 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.81)[-0.810]; MID_RHS_NOT_FQDN(0.50)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; R_DKIM_ALLOW(-0.20)[hardenedbsd.org:s=google]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; RCPT_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[hardenedbsd.org:+]; ARC_NA(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; DMARC_NA(0.00)[hardenedbsd.org]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MIME_TRACE(0.00)[0:+,1:+,2:~]; 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::d2a:from] X-Rspamd-Queue-Id: 4ZTyWX579vz3sZy X-Spamd-Bar: ---- --rk5whyzphwrh6biv Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: Heads Up: commit 2ec2ba7e232d just hit main MIME-Version: 1.0 On Sat, Apr 05, 2025 at 01:04:25AM +0000, Shawn Webb wrote: > On Fri, Apr 04, 2025 at 05:40:21PM -0700, Rick Macklem wrote: > > On Fri, Apr 4, 2025 at 10:50=E2=80=AFAM Shawn Webb wrote: > > > > > > On Thu, Apr 03, 2025 at 06:12:59PM -0700, Rick Macklem wrote: > > > > On Thu, Apr 3, 2025 at 4:52=E2=80=AFPM Shawn Webb wrote: > > > > > > > > > > On Wed, Apr 02, 2025 at 01:51:26PM -0700, Rick Macklem wrote: > > > > > > The commit 2ec2ba7e232d just hit main. I do not think it will > > > > > > cause problems, but it is fairly large. > > > > > > > > > > > > Man page updates will be done as separate commits. > > > > > > > > > > > > Hopefully this will not cause grief, rick > > > > > > > > > > Hey Rick, > > > > > > > > > > The patch review test plan mentions a patch to ZFS itself to supp= ort > > > > > named attributes. Is that patch available somewhere? > > > > The ZFS patch is currently in phabricator as D49654. > > > > Feel free to review it. > > > > > > > > It can also be found at: > > > > https://people.freebsd.org/~rmacklem/zfs-xattr.patch > > > > (this is a smaller diff which can be applied to an up-to-date main = src > > > > tree easily) > > > > > > Hey Rick, > > > > > > I applied that zfs patch, but trying pathconf(2) on a file on a ZFS > > > dataset with xattr=3Don (which seems to be the default) returns 0. Am= I > > > doing something wrong? > > > > > > =3D=3D=3D=3D BEGIN LOG =3D=3D=3D=3D > > > hbsd-current-01[shawn]:/home/shawn/tmp $ ./xattrtest xattrtest > > > xattrtest: Named attributes not enabled: No error: 0 > > > hbsd-current-01[shawn]:/home/shawn/tmp (1) $ zfs list /usr/home/shawn > > > NAME USED AVAIL REFER MOUNTPOINT > > > rpool/usr/home 10.4G 71.4G 9.85G /usr/home > > > hbsd-current-01[shawn]:/home/shawn/tmp $ zfs get xattr rpool/usr/home > > > NAME PROPERTY VALUE SOURCE > > > rpool/usr/home xattr on default > > > =3D=3D=3D=3D END LOG =3D=3D=3D=3D > > > > > > That xattrtest application is yours from: > > > https://people.freebsd.org/~rmacklem/xattrtest.c > > No idea. It works for me. You used up-to-date kernel sources? > > (Check that VIRF_NAMEDATTR is defined in sys/sys/vnode.h.) > > Oh, and one more thing to check. zfs_xattr_compat needs to be non-zero. > > (It's found in sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vnops_os.c. > > It's initialized to 1 and I don't see anything that sets it to 0?) >=20 > It is indeed set to 1. >=20 > >=20 > > The only thing I can think if is, if you changed xattr to on, you need = to > > reboot (or at least remount) to get it to take effect. > > (Maybe try setting it to "dir" and then reboot/remount. Maybe there is > > a difference between "on" and "dir"?) >=20 > Yeah, tried rebooting and still no go. Note that xattr defaults to > "on" in FreeBSD by default. My src tree is synced up to FreeBSD commit > 7e70d94acd68b3ac6b45f49d4ab7a0f7867c3ea7. I brought in the ZFS patch > you linked to. >=20 > >=20 > > Or, did you build zfs.ko some other way than as part of a kernel build? > > (It needs the patched .h files in the kernel sources, not something in > > /usr/include/sys > > that has not yet been updated.) > > All the ZFS changes are #ifdef'd, since OpenZFS requires the sources > > build for older kernels. (Basically #ifdef'd on that VIRF_NAMEDATTR men= tioned > > above.) >=20 > Perhaps I need to do a clean build. I'll try that and report back. >=20 > >=20 > > It does remind me that I need to try a build of zfs.ko by doing a "make= " in > > the module directory. > >=20 > > You can try the attached trivial patch and see if it spits out "pathcon= f ret=3D1" > > on the console. >=20 > I'll try that after a clean rebuild of the kernel. Clean rebuild didn't resolve it. However, I made some progress. I created a dataset specifically for this since I can't really unmount my /usr/home dataset, so my example down below is a bit different than the previous example I gave. The xattr property is set to "on" for the dataset. However, it's not mounted with the xattr property. In order to get it to work, I had to run the following commands: =3D=3D=3D=3D BEGIN LOG =3D=3D=3D=3D $ sudo zfs umount rpool/scratch/xattr $ sudo mount -t zfs -o xattr rpool/scratch/xattr /scratch/xattr $ zfs get xattr rpool/scratch/xattr NAME PROPERTY VALUE SOURCE rpool/scratch/xattr xattr on local $ mount | grep xattr rpool/scratch/xattr on /scratch/xattr (zfs, local, noatime, nfsv4acls, name= d attributes) $ mount | grep named rpool/scratch/xattr on /scratch/xattr (zfs, local, noatime, nfsv4acls, name= d attributes) =3D=3D=3D=3D END LOG =3D=3D=3D=3D So it looks like FreeBSD does not honor the xattr zfs property, otherwise you would see a whole bunch of datasets mounted with the "named attributes" flag in that last `mount | grep` command. --=20 Shawn Webb Cofounder / Security Engineer HardenedBSD Signal Username: shawn_webb.74 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 --rk5whyzphwrh6biv Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEA6TL67gupaZ9nzhT/y5nonf44foFAmfwhu4ACgkQ/y5nonf4 4fpoKw//cc8wGfYKzlquDDZeu+5Tn29rObqVjZcPZgbEaTFadYqd/wvAh9/P1Otx lyapsUhN550SMSYbAtkk/dPsphxpJZ8ihwPTYBYYi8DzivKRdgquJDCOy+GA7+x4 Uxs1CLjwFL02nv67sM2Mkqwn4xHJzKUOpW2b8JFxT1yzmuYCr8x5VV6+WQZti6pO HQ6r/Fy29z2ZsLh86l7yBeOmKHCm7UR6G41qTt9zhLk90WhunVrcFqhbZGiY0Qh3 PqBVArVYDFoAX6YhcsDwDxf42s2PqyrvtWeQp73X1m/R1KHcfJWWfNQ7+NU1tEKx VdXH/umSG4smJOEAkcYbD/cGOpzyjvPuCnZMpKKgWcuXLVJ4rHs+etn0WJWykuNL aePgQpOYft/eAgMVm03iYALefAekyfpVJ3lEsOefte0SeTvIMplrl2aEWYLcmMhF MdxuahT/4Xtb/UYUX2KIrZszpCd0aPKuOuHyBTU41+kc7iimphgvwB4x9ozuto5+ 5noL6d3Qn5Pw7RS7rBC5r56n2OeNivtrSBjEwYkyd7vN6kSTB6rl7m+VDYS2Al/6 sku1DU7vqA7T8vDD1tjTQr71VPQZPWCDBq4EeM8ilEBENCa6UB7fDndrjjuNHBPn ibbkfazGnjplqIx4DMuWiFCReTAagJ8j8BPjY/FI1mVsKr9zoP0= =CAq8 -----END PGP SIGNATURE----- --rk5whyzphwrh6biv-- From nobody Sat Apr 5 01:36: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 4ZTyjz397yz5sljP for ; Sat, 05 Apr 2025 01:36:23 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (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 4ZTyjy5HXyz3vpj for ; Sat, 05 Apr 2025 01:36:22 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=hardenedbsd.org header.s=google header.b=ErGfbDrJ; dmarc=none; spf=pass (mx1.freebsd.org: domain of shawn.webb@hardenedbsd.org designates 2607:f8b0:4864:20::d30 as permitted sender) smtp.mailfrom=shawn.webb@hardenedbsd.org Received: by mail-io1-xd30.google.com with SMTP id ca18e2360f4ac-85db7a3da71so229248439f.1 for ; Fri, 04 Apr 2025 18:36:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd.org; s=google; t=1743816981; x=1744421781; 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=oj6HMH2AlPud5UGxSiYK/eFAoYohvoTz1kWQKTey7pM=; b=ErGfbDrJ9UYUpgkr9JWffFljGGZEEtHaz9P6NuwhWNy618643nydJj0TRURUBiCuBW 3Z9tf4F1zZraDU2ViszcaCY9RQR5ptHgSeX2xvpBIB/kUw6td0QCgZ81X9h2VcdH7joG Soz5WO4D7ggqjEisNCXEcAQQL+Ig+Vaun5/kiaa2uc1iUAOFpkQrUFpnh+k2cKP4PZbt 1j34Ltt44v+Si7odlQ8k8/wL43dwN6CPP628Y+dWVUTp2bJCcTHO68Y0j/1uNTxPvUOK WMPzpV+Gb05TREC4YpW1VxVqHpFEKSQboPvPxS6qOB5y102QErN5stFBTPi2YqOkHj38 FKvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743816981; x=1744421781; 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=oj6HMH2AlPud5UGxSiYK/eFAoYohvoTz1kWQKTey7pM=; b=ZCPf3q8PVvmtenAMmPohSIaOrKIPKx7liSABfD4izJcTsXsj/E6l95clzMkN6EETvP w1ly9wArzPcPpm40drvUyDvsemODBbfDfM/42rlRTye3ufLddzLzQTY7k3XeLQ9PFeUA w1bWsVsIS/uWEC+aeuv1UixXSaWqzGSO0G5z8ZtY2hauEQG2sPUk9vpEEMF+ORdRpzuJ uY1Br9zrsRSk1odt98pTwTTy0maWfGRrRbbKl6cHvp8qydTWuuEXuphsfQM8FOk+jenb 3FrTKu684vJIbSZDyPw1Eoil643XYmx3MfGgl3uR+0CAaCAh51Ct+rWzV80r/LXSCTI1 YK4A== X-Gm-Message-State: AOJu0Yw1BMhd1ZaSRKVWbaOjI6KNptzX14SXdOlt5vIMr28FWU1d2DJt 7n4Xrf/3CPOH8W441PHZGDHXfjWlM8mAuzRhKHzi2s89iuYiLmzug92K8UM2symyYzVLWrXYIkU sV6E= X-Gm-Gg: ASbGncswKf1DgNc/RbRUD70KG3YW3kwB71UC0ZVNcOWGxfI81lr3BYZF6OhULh+OWj9 l5hFjysr763wMCfZxgA0tyk3O+TkVgCEMNwJ5NbHm4/szckWWIukV2pDZKr31U7bwwFutrbsEFh vXme6I8exRo8E0OXN6wSmtgPo9gFbIe+mqsL9PRvsEvF/J7Lzr2cwyAeN2O560JDRKoMKa1LVsK /9efYlsa1gdYnYaVtdWZsoLDwAyuE1a/XeWffg+JRJvz1kE8M6JbeUGyPkQSGR9XgqYxBhDnTyP Wdz+rF27kTEXUaHsch8V87GCnTs= X-Google-Smtp-Source: AGHT+IGODg8f441SLXTMXcCmY3RJgCecirv6X9Phji8hqlrHrZcW9lw0xn5CygO2gCjDVzO4PrIv4w== X-Received: by 2002:a05:6602:3a12:b0:85d:a211:9883 with SMTP id ca18e2360f4ac-8611c3bae5bmr481460239f.10.1743816981608; Fri, 04 Apr 2025 18:36:21 -0700 (PDT) Received: from mutt-hbsd ([2001:470:4001:1::95]) by smtp.gmail.com with ESMTPSA id 8926c6da1cb9f-4f4b5c3041asm1092381173.6.2025.04.04.18.36.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 04 Apr 2025 18:36:20 -0700 (PDT) Date: Sat, 5 Apr 2025 01:36:19 +0000 From: Shawn Webb To: Rick Macklem Cc: FreeBSD CURRENT Subject: Re: Heads Up: commit 2ec2ba7e232d just hit main 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: <2rq3bpvhclcipvgg3mo4gml7ysuzbvt6rfnzkprceumzeaeh4b@casrpprm6mgt> 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="5qny3xgl73u3aeli" Content-Disposition: inline In-Reply-To: X-Spamd-Result: default: False [-5.07 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.97)[-0.968]; MID_RHS_NOT_FQDN(0.50)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; R_DKIM_ALLOW(-0.20)[hardenedbsd.org:s=google]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; RCPT_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[hardenedbsd.org:+]; ARC_NA(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; DMARC_NA(0.00)[hardenedbsd.org]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MIME_TRACE(0.00)[0:+,1:+,2:~]; 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::d30:from] X-Rspamd-Queue-Id: 4ZTyjy5HXyz3vpj X-Spamd-Bar: ----- --5qny3xgl73u3aeli Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: Heads Up: commit 2ec2ba7e232d just hit main MIME-Version: 1.0 On Sat, Apr 05, 2025 at 01:27:17AM +0000, Shawn Webb wrote: > On Sat, Apr 05, 2025 at 01:04:25AM +0000, Shawn Webb wrote: > > On Fri, Apr 04, 2025 at 05:40:21PM -0700, Rick Macklem wrote: > > > On Fri, Apr 4, 2025 at 10:50=E2=80=AFAM Shawn Webb wrote: > > > > > > > > On Thu, Apr 03, 2025 at 06:12:59PM -0700, Rick Macklem wrote: > > > > > On Thu, Apr 3, 2025 at 4:52=E2=80=AFPM Shawn Webb wrote: > > > > > > > > > > > > On Wed, Apr 02, 2025 at 01:51:26PM -0700, Rick Macklem wrote: > > > > > > > The commit 2ec2ba7e232d just hit main. I do not think it will > > > > > > > cause problems, but it is fairly large. > > > > > > > > > > > > > > Man page updates will be done as separate commits. > > > > > > > > > > > > > > Hopefully this will not cause grief, rick > > > > > > > > > > > > Hey Rick, > > > > > > > > > > > > The patch review test plan mentions a patch to ZFS itself to su= pport > > > > > > named attributes. Is that patch available somewhere? > > > > > The ZFS patch is currently in phabricator as D49654. > > > > > Feel free to review it. > > > > > > > > > > It can also be found at: > > > > > https://people.freebsd.org/~rmacklem/zfs-xattr.patch > > > > > (this is a smaller diff which can be applied to an up-to-date mai= n src > > > > > tree easily) > > > > > > > > Hey Rick, > > > > > > > > I applied that zfs patch, but trying pathconf(2) on a file on a ZFS > > > > dataset with xattr=3Don (which seems to be the default) returns 0. = Am I > > > > doing something wrong? > > > > > > > > =3D=3D=3D=3D BEGIN LOG =3D=3D=3D=3D > > > > hbsd-current-01[shawn]:/home/shawn/tmp $ ./xattrtest xattrtest > > > > xattrtest: Named attributes not enabled: No error: 0 > > > > hbsd-current-01[shawn]:/home/shawn/tmp (1) $ zfs list /usr/home/sha= wn > > > > NAME USED AVAIL REFER MOUNTPOINT > > > > rpool/usr/home 10.4G 71.4G 9.85G /usr/home > > > > hbsd-current-01[shawn]:/home/shawn/tmp $ zfs get xattr rpool/usr/ho= me > > > > NAME PROPERTY VALUE SOURCE > > > > rpool/usr/home xattr on default > > > > =3D=3D=3D=3D END LOG =3D=3D=3D=3D > > > > > > > > That xattrtest application is yours from: > > > > https://people.freebsd.org/~rmacklem/xattrtest.c > > > No idea. It works for me. You used up-to-date kernel sources? > > > (Check that VIRF_NAMEDATTR is defined in sys/sys/vnode.h.) > > > Oh, and one more thing to check. zfs_xattr_compat needs to be non-zer= o. > > > (It's found in sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vnops_os= =2Ec. > > > It's initialized to 1 and I don't see anything that sets it to 0?) > >=20 > > It is indeed set to 1. > >=20 > > >=20 > > > The only thing I can think if is, if you changed xattr to on, you nee= d to > > > reboot (or at least remount) to get it to take effect. > > > (Maybe try setting it to "dir" and then reboot/remount. Maybe there is > > > a difference between "on" and "dir"?) > >=20 > > Yeah, tried rebooting and still no go. Note that xattr defaults to > > "on" in FreeBSD by default. My src tree is synced up to FreeBSD commit > > 7e70d94acd68b3ac6b45f49d4ab7a0f7867c3ea7. I brought in the ZFS patch > > you linked to. > >=20 > > >=20 > > > Or, did you build zfs.ko some other way than as part of a kernel buil= d? > > > (It needs the patched .h files in the kernel sources, not something in > > > /usr/include/sys > > > that has not yet been updated.) > > > All the ZFS changes are #ifdef'd, since OpenZFS requires the sources > > > build for older kernels. (Basically #ifdef'd on that VIRF_NAMEDATTR m= entioned > > > above.) > >=20 > > Perhaps I need to do a clean build. I'll try that and report back. > >=20 > > >=20 > > > It does remind me that I need to try a build of zfs.ko by doing a "ma= ke" in > > > the module directory. > > >=20 > > > You can try the attached trivial patch and see if it spits out "pathc= onf ret=3D1" > > > on the console. > >=20 > > I'll try that after a clean rebuild of the kernel. >=20 > Clean rebuild didn't resolve it. However, I made some progress. >=20 > I created a dataset specifically for this since I can't really unmount > my /usr/home dataset, so my example down below is a bit different than > the previous example I gave. >=20 > The xattr property is set to "on" for the dataset. However, it's not > mounted with the xattr property. In order to get it to work, I had to > run the following commands: >=20 > =3D=3D=3D=3D BEGIN LOG =3D=3D=3D=3D > $ sudo zfs umount rpool/scratch/xattr > $ sudo mount -t zfs -o xattr rpool/scratch/xattr /scratch/xattr > $ zfs get xattr rpool/scratch/xattr > NAME PROPERTY VALUE SOURCE > rpool/scratch/xattr xattr on local > $ mount | grep xattr > rpool/scratch/xattr on /scratch/xattr (zfs, local, noatime, nfsv4acls, na= med attributes) > $ mount | grep named > rpool/scratch/xattr on /scratch/xattr (zfs, local, noatime, nfsv4acls, na= med attributes) > =3D=3D=3D=3D END LOG =3D=3D=3D=3D >=20 > So it looks like FreeBSD does not honor the xattr zfs property, > otherwise you would see a whole bunch of datasets mounted with the > "named attributes" flag in that last `mount | grep` command. Here's a little test program I whipped up to copy a shared object into an extended attribute, then fdlopen the attribute: https://git.hardenedbsd.org/shawn.webb/random-code/-/commit/32544bcccd29b43= c2fd70a33e0c685cebb0fdbdf It's an ugly PoC, but it works. :-) --=20 Shawn Webb Cofounder / Security Engineer HardenedBSD Signal Username: shawn_webb.74 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 --5qny3xgl73u3aeli Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEA6TL67gupaZ9nzhT/y5nonf44foFAmfwiRMACgkQ/y5nonf4 4frNNA/8D6TbKj6hSoSfahsByWEP5Rx0nOPfeHEaHXk0cxhJ1wtWFB/Mba0xSgs0 4l1OlIgD8QR0mnp7LHW1LwbuBFygbPeXUqIhVzoKVNeIkSLfrIZaMM9Q8oEq5vNA SNNKb9NWtp8uW17/PeQ01FJPWNKHg/eH3wICV6O/FTq4YZVVtHRNfnTBWKuSIrRV MTzOEKfPcpcxuNVMHMYPwhcSGX8nN8xBey4jjueGAZKgnLMyU1kJuTET2/1cJSfA Kod+vdI+SG65Tuzh8apdggNa6zTmBlajNLTzpgBhX/l6F89o86+uaZ82/MRHeFDS 8BClLkiLqSIOXlD3EH4JITXzgPp8kl9MnXgrkybIxn7JylKlNbAupZWLaW4V2SSO l2hyONSn1ednWcHhDQbFnxuq8GnbDiR1NxogsoELNIKJukqxdi1H4YGeCuVexvh2 Wb6jWToiz39L0Qd5zNi5c8jYeAP+HGpAI/x2xlg+/he8LqVP4Mfdu1AnpSGO3R4e 1UqCSv6B5pQuncP0tIf2QvViDaM4NknJF9lykDAiibk6vAHk9Dc4vkA6vFfR5+fl DIHiJCTRHQjACoVbcgpmPzcY2pPKMIUeKu4esBFgUfWN/npNthoPWEH+hYhLWQx3 Z+WEAJ6u0g1MoWkxxA/gdgIwrVKsPXe98Vnhcs32YTIWGwm26PM= =n6Dc -----END PGP SIGNATURE----- --5qny3xgl73u3aeli-- From nobody Sat Apr 5 01:45:53 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 4ZTyx82McFz5slsn for ; Sat, 05 Apr 2025 01:46:04 +0000 (UTC) (envelope-from kargls@comcast.net) Received: from resqmta-c2p-546593.sys.comcast.net (resqmta-c2p-546593.sys.comcast.net [IPv6:2001:558:fd00:56::8]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZTyx66QYKz40bS for ; Sat, 05 Apr 2025 01:46:02 +0000 (UTC) (envelope-from kargls@comcast.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=comcast.net header.s=20190202a header.b=cqcA33h9; dmarc=pass (policy=quarantine) header.from=comcast.net; spf=pass (mx1.freebsd.org: domain of kargls@comcast.net designates 2001:558:fd00:56::8 as permitted sender) smtp.mailfrom=kargls@comcast.net Received: from resomta-c2p-555442.sys.comcast.net ([96.102.18.241]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 256/256 bits) (Client did not present a certificate) by resqmta-c2p-546593.sys.comcast.net with ESMTPS id 0sLUugB3Kh0X60sbbuu4Hd; Sat, 05 Apr 2025 01:45:55 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=20190202a; t=1743817555; bh=NlpG7SutD5fIsHJTuwE5jM/tqHnVsuf22HQIrWhnn7w=; h=Received:Received:Message-ID:Date:MIME-Version:To:From:Subject: Content-Type:Xfinity-Spam-Result; b=cqcA33h9RwtR7YcBH0W+bb6h9ydgxNfl15JD2vp091rIglRKmN1okmG5mjGIHryOy iC9vfx7a5i8HU8tdyGWpthl3zIjiBw811boNnt+BiOc5K7PVyFsHdNTJtszxecV8CO jsEqW7dH1oL9U0oE9PrBUolKTnGWh/OlbV6qaUgcuPsgvkodAVAActx3J5VjSaJTSK 0go0u+wgjuXcDMnTxVRI69hlm8VqfR5TRKYhZQDwwaZuPY6yWF0Lnfj8nNTc58yEZ1 FNBAm/aj6RsZhP0+hrAo7lXPzroQogR5CxWguIkTmuGTA8nBlFMWKxuQBp3emm0Cw4 dTyt+unn5zpHQ== Received: from [10.0.0.30] ([73.83.213.54]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 256/256 bits) (Client did not present a certificate) by resomta-c2p-555442.sys.comcast.net with ESMTPSA id 0sbZuhGe8mUGU0sbau7aDV; Sat, 05 Apr 2025 01:45:54 +0000 Message-ID: <39bd6092-4bd9-4086-b202-08b83b425fb5@comcast.net> Date: Fri, 4 Apr 2025 18:45:53 -0700 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 Content-Language: en-US To: freebsd-current@freebsd.org From: Steve Kargl Subject: Samsung T7 external SSD support? Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4xfFsm0Lw4tmIOClBnFExloXMTyzGjsoKtI7Q/bxArMs1a+rfzHo5/neBRYWzWBL9tXdSoRJH6gXKdErLEFUDJgYn1dTH6OqNtVT5r2yFHfJyfBRzMX4kU fdfxGjwsWHopUslieVl+uFTrCkPX7HVu1nc02A8byA14OCfNJs6i5WphNihISPg5xfrOtVeHJF5EOw== X-Spamd-Result: default: False [0.49 / 15.00]; HFILTER_HELO_5(3.00)[resqmta-c2p-546593.sys.comcast.net]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-0.999]; NEURAL_HAM_SHORT(-0.51)[-0.510]; DMARC_POLICY_ALLOW(-0.50)[comcast.net,quarantine]; R_DKIM_ALLOW(-0.20)[comcast.net:s=20190202a]; R_SPF_ALLOW(-0.20)[+ip6:2001:558:fd00:56::/64]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_NONE(0.00)[comcast.net:dkim]; MIME_TRACE(0.00)[0:+]; FREEMAIL_FROM(0.00)[comcast.net]; FROM_HAS_DN(0.00)[]; FREEMAIL_ENVFROM(0.00)[comcast.net]; TO_DN_NONE(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[comcast.net:+]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:7922, ipnet:2001:558::/29, country:US]; RCVD_IN_DNSWL_NONE(0.00)[96.102.18.241:received] X-Rspamd-Queue-Id: 4ZTyx66QYKz40bS X-Spamd-Bar: / Anyone using a Samsung T7 external SSD with FreeBSD current? If I plug the drive into a USB 2.0 port, I see usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage device Samsung PSSD T7 Shield (0x04e8:0x61fb) ugen0.2: at usbus0 umass0 on uhub1 umass0: on usbus0 umass0: SCSI over Bulk-Only; quirks = 0x0100 umass0:5:0: Attached to scbus5 da0 at umass-sim0 bus 0 scbus5 target 0 lun 0 da0: Fixed Direct Access SPC-4 SCSI device da0: Serial Number S6NPNS0Y201077Y da0: 40.000MB/s transfers da0: 1907729MB (3907029168 512 byte sectors) da0: quirks=0x2 However, the SSD is supposedly a USB 3.2 gen 2 device with a ~1000 MBps read/write speed. When plugged into a USB 3.x port, I typically see ugen0.2: at usbus0 and the device is not listed with usbconfig. Repeatedly, unplugging the ssd and re-plugging it into the USB 3.x port, I eventually get the above dmesg output. Do I need a quirk for this SSD to get recognized? Also, shouldn't it connect with faster transfer rate than 'da0: 40.0MB/s'? -- steve From nobody Sat Apr 5 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 4ZTzt95zRQz5sp6S for ; Sat, 05 Apr 2025 02:28:33 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-yw1-x112d.google.com (mail-yw1-x112d.google.com [IPv6:2607:f8b0:4864:20::112d]) (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 4ZTzt831HDz46qL for ; Sat, 05 Apr 2025 02:28:32 +0000 (UTC) (envelope-from mavbsd@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-yw1-x112d.google.com with SMTP id 00721157ae682-6fee50bfea5so23290207b3.1 for ; Fri, 04 Apr 2025 19:28:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1743820111; x=1744424911; darn=freebsd.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date:message-id:reply-to; bh=RHeKFFqBa7mx9LdzapctLcpfa4PELV9dVdGz/R5jj0U=; b=NsZvZYlSCyAlJK+5ekiGeVxMK8NZIvWagRIOx/eUAR88hJZMgLMw/rgGFJE/aG6LjC 5xNaPsXWB7GehRbGITcM1TGXBnShgyEuuMfSiiIztcvuzBbycV6PLqpGUpJgivoUq9pH 5+cUZ6+s0iFt0NRQjsG3dt6ftGDdn6oJ/rOj5LBFsPfayuFZkqVCo8NieZNCr6aCCIoZ D2yeZnOTQZpwKA2rBUlmdv0PBeOIfZ/9j0C150bHlXMvI/X05G1MN4RxrRGrJJOjWNRv 9iHPmORf9+j6XvnPksKlnrto2/u2d0G4NnOev2D7+lwIeP8lqueY/RXXhG83jUW4WSjD CX5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743820111; x=1744424911; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=RHeKFFqBa7mx9LdzapctLcpfa4PELV9dVdGz/R5jj0U=; b=dc/r18aj9HOQtfipDVzX36+d8xBNJdxCIvmT/NxBGwatWAfDl1mrIKOWs4+37L5UDE EMR92R8eDHSCCnpD5ynw19qGSBCEtX0vaFxGDdrpHpolViFdvCegW/hUf1b3CDhw0tYp KRiG4FwSUv/4Wsj1zJPt+3OQS4ss/l/mqxUgf7k5+DQrwb1UxgtQ27jWsxJo/4eE9W6m 3mJtSTMqrfM+bfhl6fO1EJ7dpHw3RcOYZ7XsWTHu2PAMBubrw3bzxR/ebfzAWO59WhEE 36uArchkZey3NasxFTk4uV1a8vx1qQDTgrmHz0VH0bDMIXhu5fLnqTgVcTrQWYpVQI+K 0B8Q== X-Forwarded-Encrypted: i=1; AJvYcCVS4vGsNMOqSwnc79J7aGa8b6+yY3jC49MwF5cQM+9A8X7k6oWEv3LA13MNhP6hXgB0KHHazFT3Nain690OwVE=@freebsd.org X-Gm-Message-State: AOJu0YzF6qJfxC49JbyYkNXweqNQqSg4JfExzGWmKiQBnwl5lCPQNfXP X7R9zSbLyR8RVJe/K6uzlnsYpGHqStVgHrCBa8vy6pUSxdH2TfB6 X-Gm-Gg: ASbGnctsMPYjeXSKuwPCQDriQ3utHvb4ojH0nXE133xuqUOIFSkJfjDY4YfjEiHH3Uu fAcLUdSUkceKLahyOlPvu8AOcHB8Lzep7YTAdKnHCrvFPJN33yOlxeDvpg5/WQJD+SvPTL9r0KL yz69VLYfQ70R4Alrg4Njgw0W9Oqz+Yaa/ZY+nDUh32n6n0XEsGysIXnmG1RYlTceobUq5c/GYU3 I5VBp6XKk73rHo86gZC3USq4SqNpcxX/X5FAh8meqmmdoBENfBODfe8/RBAqkIBGt8A6QgF8XsY CAZ7XMQDBvHyrtxFW8IBTTfqlFt32uCm4c/Un6EEESytKxgLjmo0Br0UO1JW+VvuhcBYMipQ8FQ AnTblSy7KKcY0 X-Google-Smtp-Source: AGHT+IEixOWtbf/Bd507MomGuYuK+vvMNkOqP1ps3QI9Jr5m2MZyKzNHpaPqIKSmzlgDn2jV4cTeWw== X-Received: by 2002:a05:690c:6106:b0:700:b007:a33e with SMTP id 00721157ae682-703e154f99emr91997307b3.16.1743820111444; Fri, 04 Apr 2025 19:28:31 -0700 (PDT) Received: from ?IPV6:2600:1700:3580:3560:a236:9fff:fe4f:c69a? ([2600:1700:3580:3560:a236:9fff:fe4f:c69a]) by smtp.gmail.com with ESMTPSA id 00721157ae682-703d1e5c38asm12009077b3.46.2025.04.04.19.28.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 04 Apr 2025 19:28:30 -0700 (PDT) Message-ID: <35d2361d-80e8-489a-bd9d-6c5ada5736b8@FreeBSD.org> Date: Fri, 4 Apr 2025 22:28:32 -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: Samsung T7 external SSD support? To: Steve Kargl , freebsd-current@freebsd.org References: <39bd6092-4bd9-4086-b202-08b83b425fb5@comcast.net> Content-Language: en-US From: Alexander Motin In-Reply-To: <39bd6092-4bd9-4086-b202-08b83b425fb5@comcast.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4ZTzt831HDz46qL X-Spamd-Bar: ---- On 04.04.2025 21:45, Steve Kargl wrote: > Anyone using a Samsung T7 external SSD with FreeBSD current? > > If I plug the drive into a USB 2.0 port, I see > > usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage device > Samsung PSSD T7 Shield (0x04e8:0x61fb) > ugen0.2: at usbus0 > umass0 on uhub1 > umass0: on > usbus0 > umass0:  SCSI over Bulk-Only; quirks = 0x0100 > umass0:5:0: Attached to scbus5 > da0 at umass-sim0 bus 0 scbus5 target 0 lun 0 > da0: Fixed Direct Access SPC-4 SCSI device > da0: Serial Number S6NPNS0Y201077Y > da0: 40.000MB/s transfers > da0: 1907729MB (3907029168 512 byte sectors) > da0: quirks=0x2 > > However, the SSD is supposedly a USB 3.2 gen 2 device with a ~1000 MBps > read/write speed. > > When plugged into a USB 3.x port, I typically see > > ugen0.2: at usbus0 > > and the device is not listed with usbconfig.  Repeatedly, unplugging the > ssd and re-plugging it into the USB 3.x port, I eventually get the above > dmesg output.  Do I need a quirk for this SSD to get recognized?  Also, > shouldn't it connect with faster transfer rate than 'da0: 40.0MB/s'? 40MB/s exactly means the device connected to USB2 controller or at least at USB2 speed. Considering that other times it does not connect at all, I wonder if some signal quality issue or something else prevents it from going proper USB3. IIRC USB3 uses completely different wires in the connector. Also USB2 and USB3 can be handled by different controllers with different drivers, so not detecting it still might be a software issue, but I can't say much about that area. -- Alexander Motin From nobody Sat Apr 5 02:40: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 4ZV0820fF0z5sq80 for ; Sat, 05 Apr 2025 02:40:34 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (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 4ZV0815Dtmz49YN for ; Sat, 05 Apr 2025 02:40:33 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x52c.google.com with SMTP id 4fb4d7f45d1cf-5e5e0caa151so4732732a12.0 for ; Fri, 04 Apr 2025 19:40:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1743820831; x=1744425631; 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=arUgvHL0EOMUXayBes8VJP6gcOptEOVE6fIkIQYU1Xg=; b=ho/7xqfiQfL/QS0NQzjY9CcL0Vxkd+HZ1FElKJonmH98tbL8uoOLPLtiWrYtXNfJDA 2Yy/JEM6ajWgeBx2BDEv5GHZGFhx38hfP3HK4JBN6XVYIDQKb+V0pBvkiJDm8SR8dGfU bRZ7JFZb9XaiSyiVlI/gELqJh+rzkei12p10546VXdhnlKGF2mUvoDHvSHHjYVsDQ2MJ oK9+1Geeu4bhHrE4t2Win4UunEr3vpbWlcRFqL9XQ2efqr1xGyAnxpNIXY+mhuU8X3GJ 0Hf8IGKY+23absu6aRhX6lcHgV9xA3qNbbCuUGOo05EO6TcrG1OsjnDCSyo/XM/CU5a5 Lung== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743820831; x=1744425631; 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=arUgvHL0EOMUXayBes8VJP6gcOptEOVE6fIkIQYU1Xg=; b=lnZ45DOy1CShw6CGyabzFXBjIxjLydKkYRtKLVVauV0uleOp98SoMuxOi0zI+6euJE 4CAQ7yx1byOAldaubs1d0JqbL8NWPceAH9GWqjtE8mrxjTrZsYyvd74rxUdzOVusS8dg ByDmxKUT3C8jrv1itOjoNUpQISb0znUnMGcy1StSSQfi+KhKCpaVmmarB2iFciLWPPWK 8dcqiunqfsgUKxU0KibZC5hY7z1a+8Piby7he+ZGOVbqXfzmXLbkE6FQCY5NB/+JtJc7 ihs3HF8s+NLsfTrWa0jSufR4ggjBIDlhq6QCGr3Jf8mHp7yLPrePVS2iqe7/yDKjef57 6ifQ== X-Gm-Message-State: AOJu0Ywuur7Ia0UMZSFxTghp5L4HaUv4SZNNajbaH+XihA4shRhM8PSz N/i0Benp6izBWWvK4I8jKBONsNJXyZOhCY29O9tLKueDr7NeqBPR+9pDV1TGEqOwfn3PLihP2xt Q7r44WpS58E+zg7P/0PhLa4Sv0g== X-Gm-Gg: ASbGncvPOBf8ez+yYkLm72iiTOd5p+TG+ALX/4MiwbhlsgMgxW3/Kq9JV0PezjtfthA UuDJkkfwyFaQQi8nUuPfUqcrjiQ4+xLbUlGFZd6I2UvTTKMN9MlnGTDyon5BMQUM0WTmHd1eQbg RdE+oqyS24UVeHufZuMYXZXmkjimZABeRDw7gL5A0FqznhG8Z0KYaCvtu8Pz67eEKTLoOA X-Google-Smtp-Source: AGHT+IG/yyvZaFUp2lKp8luvTAgH3i3ww43EdrXS3G5rRgewuQaCJHZadchF0xA/PnFrjBhLLaHjjUIv3IleOJTXHbE= X-Received: by 2002:a05:6402:350f:b0:5f0:48df:25ae with SMTP id 4fb4d7f45d1cf-5f0b5d8b510mr4187833a12.2.1743820831115; Fri, 04 Apr 2025 19:40:31 -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: <2rq3bpvhclcipvgg3mo4gml7ysuzbvt6rfnzkprceumzeaeh4b@casrpprm6mgt> In-Reply-To: From: Rick Macklem Date: Fri, 4 Apr 2025 19:40:20 -0700 X-Gm-Features: ATxdqUF381j8NmXS6JZdrqIcahQfWl3xd-V1aU9Wet2GU2ytNlsL35mqFWioo5A Message-ID: Subject: Re: Heads Up: commit 2ec2ba7e232d just hit main To: Shawn Webb Cc: FreeBSD CURRENT 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: 4ZV0815Dtmz49YN X-Spamd-Bar: ---- On Fri, Apr 4, 2025 at 6:27=E2=80=AFPM Shawn Webb wrote: > > On Sat, Apr 05, 2025 at 01:04:25AM +0000, Shawn Webb wrote: > > On Fri, Apr 04, 2025 at 05:40:21PM -0700, Rick Macklem wrote: > > > On Fri, Apr 4, 2025 at 10:50=E2=80=AFAM Shawn Webb wrote: > > > > > > > > On Thu, Apr 03, 2025 at 06:12:59PM -0700, Rick Macklem wrote: > > > > > On Thu, Apr 3, 2025 at 4:52=E2=80=AFPM Shawn Webb wrote: > > > > > > > > > > > > On Wed, Apr 02, 2025 at 01:51:26PM -0700, Rick Macklem wrote: > > > > > > > The commit 2ec2ba7e232d just hit main. I do not think it wil= l > > > > > > > cause problems, but it is fairly large. > > > > > > > > > > > > > > Man page updates will be done as separate commits. > > > > > > > > > > > > > > Hopefully this will not cause grief, rick > > > > > > > > > > > > Hey Rick, > > > > > > > > > > > > The patch review test plan mentions a patch to ZFS itself to su= pport > > > > > > named attributes. Is that patch available somewhere? > > > > > The ZFS patch is currently in phabricator as D49654. > > > > > Feel free to review it. > > > > > > > > > > It can also be found at: > > > > > https://people.freebsd.org/~rmacklem/zfs-xattr.patch > > > > > (this is a smaller diff which can be applied to an up-to-date mai= n src > > > > > tree easily) > > > > > > > > Hey Rick, > > > > > > > > I applied that zfs patch, but trying pathconf(2) on a file on a ZFS > > > > dataset with xattr=3Don (which seems to be the default) returns 0. = Am I > > > > doing something wrong? > > > > > > > > =3D=3D=3D=3D BEGIN LOG =3D=3D=3D=3D > > > > hbsd-current-01[shawn]:/home/shawn/tmp $ ./xattrtest xattrtest > > > > xattrtest: Named attributes not enabled: No error: 0 > > > > hbsd-current-01[shawn]:/home/shawn/tmp (1) $ zfs list /usr/home/sha= wn > > > > NAME USED AVAIL REFER MOUNTPOINT > > > > rpool/usr/home 10.4G 71.4G 9.85G /usr/home > > > > hbsd-current-01[shawn]:/home/shawn/tmp $ zfs get xattr rpool/usr/ho= me > > > > NAME PROPERTY VALUE SOURCE > > > > rpool/usr/home xattr on default > > > > =3D=3D=3D=3D END LOG =3D=3D=3D=3D > > > > > > > > That xattrtest application is yours from: > > > > https://people.freebsd.org/~rmacklem/xattrtest.c > > > No idea. It works for me. You used up-to-date kernel sources? > > > (Check that VIRF_NAMEDATTR is defined in sys/sys/vnode.h.) > > > Oh, and one more thing to check. zfs_xattr_compat needs to be non-zer= o. > > > (It's found in sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vnops_os= .c. > > > It's initialized to 1 and I don't see anything that sets it to 0?) > > > > It is indeed set to 1. > > > > > > > > The only thing I can think if is, if you changed xattr to on, you nee= d to > > > reboot (or at least remount) to get it to take effect. > > > (Maybe try setting it to "dir" and then reboot/remount. Maybe there i= s > > > a difference between "on" and "dir"?) > > > > Yeah, tried rebooting and still no go. Note that xattr defaults to > > "on" in FreeBSD by default. My src tree is synced up to FreeBSD commit > > 7e70d94acd68b3ac6b45f49d4ab7a0f7867c3ea7. I brought in the ZFS patch > > you linked to. > > > > > > > > Or, did you build zfs.ko some other way than as part of a kernel buil= d? > > > (It needs the patched .h files in the kernel sources, not something i= n > > > /usr/include/sys > > > that has not yet been updated.) > > > All the ZFS changes are #ifdef'd, since OpenZFS requires the sources > > > build for older kernels. (Basically #ifdef'd on that VIRF_NAMEDATTR m= entioned > > > above.) > > > > Perhaps I need to do a clean build. I'll try that and report back. > > > > > > > > It does remind me that I need to try a build of zfs.ko by doing a "ma= ke" in > > > the module directory. > > > > > > You can try the attached trivial patch and see if it spits out "pathc= onf ret=3D1" > > > on the console. > > > > I'll try that after a clean rebuild of the kernel. > > Clean rebuild didn't resolve it. However, I made some progress. > > I created a dataset specifically for this since I can't really unmount > my /usr/home dataset, so my example down below is a bit different than > the previous example I gave. > > The xattr property is set to "on" for the dataset. However, it's not > mounted with the xattr property. In order to get it to work, I had to > run the following commands: > > =3D=3D=3D=3D BEGIN LOG =3D=3D=3D=3D > $ sudo zfs umount rpool/scratch/xattr > $ sudo mount -t zfs -o xattr rpool/scratch/xattr /scratch/xattr > $ zfs get xattr rpool/scratch/xattr > NAME PROPERTY VALUE SOURCE > rpool/scratch/xattr xattr on local > $ mount | grep xattr > rpool/scratch/xattr on /scratch/xattr (zfs, local, noatime, nfsv4acls, na= med attributes) > $ mount | grep named > rpool/scratch/xattr on /scratch/xattr (zfs, local, noatime, nfsv4acls, na= med attributes) > =3D=3D=3D=3D END LOG =3D=3D=3D=3D > > So it looks like FreeBSD does not honor the xattr zfs property, > otherwise you would see a whole bunch of datasets mounted with the > "named attributes" flag in that last `mount | grep` command. Thanks for the info. For some reason, I never had to do this. I do remember fiddling around with the xattr property, setting it to sa and then to dir. Each time I rebooted the system to make the change take effect. I did notice I had to reboot to get the change in xattr setting to take eff= ect. (I wonder if the default "on" somehow doesn't take effect, but changing it to "sa" and then "dir" somehow does?) Anyhow, I'll try to incorporate the unmount/mount with the xattr option int= o the man page I need to write. Thanks for figuring this out, rick > > -- > Shawn Webb > Cofounder / Security Engineer > HardenedBSD > > Signal Username: shawn_webb.74 > 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 Apr 5 02:44: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 4ZV0DV3zwfz5sqlP for ; Sat, 05 Apr 2025 02:44:26 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) (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 4ZV0DV25gFz3DBV for ; Sat, 05 Apr 2025 02:44:26 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x52f.google.com with SMTP id 4fb4d7f45d1cf-5e60cfef9cfso4215671a12.2 for ; Fri, 04 Apr 2025 19:44:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1743821065; x=1744425865; 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=TLeEKkH/MltK8rE0bQ0M+wqvA+9g7PFHAqxJCu4dgjQ=; b=bGbJNTE0bjKtFHvgAQIz1hY6pfZH1fiwXsuyhKBKzBgyFxhUO/H8/cgVCn1lvxfMRM DSBqKR4Zzmr5v0Vlq8x0ZaNjdqWgx5kQwibDRNPWD89Stv2pqtbqwJqb2HasiFkQhSXR ZHa+tiJm0LR7g6vVP/FCFVSxhNjlnXIeIHoTOIJ/GuSwumWxZAo2KQE3rteDoI2RR4DO 4yNOenq3RYWSaEi8eCvODnW61G2WgtNZXQd8fmidyNm72jaze1QQyqLkDqil39BqElrA x/7uHbLRo7NSGLk3urrYFN5khkHpquu1LpmbaMK5qSlzQG81nYkXJHuXOcjaHKMMEv/7 rolw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743821065; x=1744425865; 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=TLeEKkH/MltK8rE0bQ0M+wqvA+9g7PFHAqxJCu4dgjQ=; b=JsIkWqGXzcnG1t2ki8gt86o+CShVGnOaBRftrrhHRXL7DeMQ74xgVPQC7ZsOjkPNoP JQtkZGoCRs2jqJRaS4fRq5NYSNbrTQhLQz7MLkvwktFXBqoYihUAuu5/hQVko6RLrK9c 21YovJf7qq7QR1UmO9caxP2Svw/dy4Ri2NTyAq0f9s6+8pdtqsdFU5toJ0AKU7MWacls /cwOEMAjfGtffXqLOKkKu99QeQtwPEzonwZ6nR64EuKaLy+oYZilbmKSfkUgJIbVbco4 ppmZtbKuBwQRlVECgDzbKspFA924DIfpKzUZpSvwUivTb58saTMq6iE9XHcN/FXiVt3U 95mQ== X-Gm-Message-State: AOJu0YwbjqkQ/IZWN6PaAzhgtUkvbM6S+Wu/BarjkBZvQFqn3os4EigF FuTXtq+Xcc25NgtQRv63W8/+FaQmaYKPh3e+Oh/WnibTyvejTobCqg1Foq+0U29rn4taRgubXQm RR5C2yGOuGG+g1Ty4fSuLTCxiKw== X-Gm-Gg: ASbGncuqSbWgMsPsr/w93lxXuO9tPqFRsyC65ivmItM5J6ZBsatPXqENCTddnJ+tdyM fT7e71NXUKFx9cCrKfIzHyDxLmdtF5wiMtUpU/tpivOYX6fbn8Vc7/Saf3JoGsle74a4TC8peW5 OH4fvxcu7CtsL0e3oM42qkNwnSyjKx31r+E4mUy41rfDJFwNZ3VXhvueqzSw== X-Google-Smtp-Source: AGHT+IH0i8IlZQmXuiip9YcgeglZaZ8DPzetK6WbUpLruioX6ITJ6PGRR54B9e7DT8c8p5xyzwBCr7a6iwozYEU4+pA= X-Received: by 2002:a05:6402:430e:b0:5ed:61c8:adcf with SMTP id 4fb4d7f45d1cf-5f0db81a6b2mr954440a12.15.1743821064439; Fri, 04 Apr 2025 19:44:24 -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: <2rq3bpvhclcipvgg3mo4gml7ysuzbvt6rfnzkprceumzeaeh4b@casrpprm6mgt> In-Reply-To: From: Rick Macklem Date: Fri, 4 Apr 2025 19:44:13 -0700 X-Gm-Features: ATxdqUH1geFc0yWgdIxsVz4ghsGzcb27vtW-b__yzi6j9bJCX5qJp1WzvHK0Gyg Message-ID: Subject: Re: Heads Up: commit 2ec2ba7e232d just hit main To: Shawn Webb Cc: FreeBSD CURRENT 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: 4ZV0DV25gFz3DBV X-Spamd-Bar: ---- On Fri, Apr 4, 2025 at 6:36=E2=80=AFPM Shawn Webb wrote: > > On Sat, Apr 05, 2025 at 01:27:17AM +0000, Shawn Webb wrote: > > On Sat, Apr 05, 2025 at 01:04:25AM +0000, Shawn Webb wrote: > > > On Fri, Apr 04, 2025 at 05:40:21PM -0700, Rick Macklem wrote: > > > > On Fri, Apr 4, 2025 at 10:50=E2=80=AFAM Shawn Webb wrote: > > > > > > > > > > On Thu, Apr 03, 2025 at 06:12:59PM -0700, Rick Macklem wrote: > > > > > > On Thu, Apr 3, 2025 at 4:52=E2=80=AFPM Shawn Webb wrote: > > > > > > > > > > > > > > On Wed, Apr 02, 2025 at 01:51:26PM -0700, Rick Macklem wrote: > > > > > > > > The commit 2ec2ba7e232d just hit main. I do not think it w= ill > > > > > > > > cause problems, but it is fairly large. > > > > > > > > > > > > > > > > Man page updates will be done as separate commits. > > > > > > > > > > > > > > > > Hopefully this will not cause grief, rick > > > > > > > > > > > > > > Hey Rick, > > > > > > > > > > > > > > The patch review test plan mentions a patch to ZFS itself to = support > > > > > > > named attributes. Is that patch available somewhere? > > > > > > The ZFS patch is currently in phabricator as D49654. > > > > > > Feel free to review it. > > > > > > > > > > > > It can also be found at: > > > > > > https://people.freebsd.org/~rmacklem/zfs-xattr.patch > > > > > > (this is a smaller diff which can be applied to an up-to-date m= ain src > > > > > > tree easily) > > > > > > > > > > Hey Rick, > > > > > > > > > > I applied that zfs patch, but trying pathconf(2) on a file on a Z= FS > > > > > dataset with xattr=3Don (which seems to be the default) returns 0= . Am I > > > > > doing something wrong? > > > > > > > > > > =3D=3D=3D=3D BEGIN LOG =3D=3D=3D=3D > > > > > hbsd-current-01[shawn]:/home/shawn/tmp $ ./xattrtest xattrtest > > > > > xattrtest: Named attributes not enabled: No error: 0 > > > > > hbsd-current-01[shawn]:/home/shawn/tmp (1) $ zfs list /usr/home/s= hawn > > > > > NAME USED AVAIL REFER MOUNTPOINT > > > > > rpool/usr/home 10.4G 71.4G 9.85G /usr/home > > > > > hbsd-current-01[shawn]:/home/shawn/tmp $ zfs get xattr rpool/usr/= home > > > > > NAME PROPERTY VALUE SOURCE > > > > > rpool/usr/home xattr on default > > > > > =3D=3D=3D=3D END LOG =3D=3D=3D=3D > > > > > > > > > > That xattrtest application is yours from: > > > > > https://people.freebsd.org/~rmacklem/xattrtest.c > > > > No idea. It works for me. You used up-to-date kernel sources? > > > > (Check that VIRF_NAMEDATTR is defined in sys/sys/vnode.h.) > > > > Oh, and one more thing to check. zfs_xattr_compat needs to be non-z= ero. > > > > (It's found in sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vnops_= os.c. > > > > It's initialized to 1 and I don't see anything that sets it to 0?) > > > > > > It is indeed set to 1. > > > > > > > > > > > The only thing I can think if is, if you changed xattr to on, you n= eed to > > > > reboot (or at least remount) to get it to take effect. > > > > (Maybe try setting it to "dir" and then reboot/remount. Maybe there= is > > > > a difference between "on" and "dir"?) > > > > > > Yeah, tried rebooting and still no go. Note that xattr defaults to > > > "on" in FreeBSD by default. My src tree is synced up to FreeBSD commi= t > > > 7e70d94acd68b3ac6b45f49d4ab7a0f7867c3ea7. I brought in the ZFS patch > > > you linked to. > > > > > > > > > > > Or, did you build zfs.ko some other way than as part of a kernel bu= ild? > > > > (It needs the patched .h files in the kernel sources, not something= in > > > > /usr/include/sys > > > > that has not yet been updated.) > > > > All the ZFS changes are #ifdef'd, since OpenZFS requires the source= s > > > > build for older kernels. (Basically #ifdef'd on that VIRF_NAMEDATTR= mentioned > > > > above.) > > > > > > Perhaps I need to do a clean build. I'll try that and report back. > > > > > > > > > > > It does remind me that I need to try a build of zfs.ko by doing a "= make" in > > > > the module directory. > > > > > > > > You can try the attached trivial patch and see if it spits out "pat= hconf ret=3D1" > > > > on the console. > > > > > > I'll try that after a clean rebuild of the kernel. > > > > Clean rebuild didn't resolve it. However, I made some progress. > > > > I created a dataset specifically for this since I can't really unmount > > my /usr/home dataset, so my example down below is a bit different than > > the previous example I gave. > > > > The xattr property is set to "on" for the dataset. However, it's not > > mounted with the xattr property. In order to get it to work, I had to > > run the following commands: > > > > =3D=3D=3D=3D BEGIN LOG =3D=3D=3D=3D > > $ sudo zfs umount rpool/scratch/xattr > > $ sudo mount -t zfs -o xattr rpool/scratch/xattr /scratch/xattr > > $ zfs get xattr rpool/scratch/xattr > > NAME PROPERTY VALUE SOURCE > > rpool/scratch/xattr xattr on local > > $ mount | grep xattr > > rpool/scratch/xattr on /scratch/xattr (zfs, local, noatime, nfsv4acls, = named attributes) > > $ mount | grep named > > rpool/scratch/xattr on /scratch/xattr (zfs, local, noatime, nfsv4acls, = named attributes) > > =3D=3D=3D=3D END LOG =3D=3D=3D=3D > > > > So it looks like FreeBSD does not honor the xattr zfs property, > > otherwise you would see a whole bunch of datasets mounted with the > > "named attributes" flag in that last `mount | grep` command. > > Here's a little test program I whipped up to copy a shared object into > an extended attribute, then fdlopen the attribute: > https://git.hardenedbsd.org/shawn.webb/random-code/-/commit/32544bcccd29b= 43c2fd70a33e0c685cebb0fdbdf > > It's an ugly PoC, but it works. :-) I wouldn't call it ugly. It looks fine to me. On the other hand, the test programs I use (I have a bunch of them now) are definitely ugly.;-) Thanks for trying this, rick > > -- > Shawn Webb > Cofounder / Security Engineer > HardenedBSD > > Signal Username: shawn_webb.74 > 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 Apr 5 02:44:49 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 4ZV0F72vGZz5sqlT for ; Sat, 05 Apr 2025 02:44:59 +0000 (UTC) (envelope-from kargls@comcast.net) Received: from resqmta-c2p-570216.sys.comcast.net (resqmta-c2p-570216.sys.comcast.net [IPv6:2001:558:fd00:56::6]) (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 4ZV0F654Jnz3DWv for ; Sat, 05 Apr 2025 02:44:58 +0000 (UTC) (envelope-from kargls@comcast.net) Authentication-Results: mx1.freebsd.org; none Received: from resomta-c2p-555954.sys.comcast.net ([96.102.18.234]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 256/256 bits) (Client did not present a certificate) by resqmta-c2p-570216.sys.comcast.net with ESMTPS id 0tAZuTI3tW5O50tWduSSBT; Sat, 05 Apr 2025 02:44:51 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=20190202a; t=1743821091; bh=klvJwwLKr0pYj4RtR8A1my4giIm4z3oZ8zon4Gn7yYU=; h=Received:Received:Message-ID:Date:MIME-Version:Subject:To:From: Content-Type:Xfinity-Spam-Result; b=H7cxuYqBC1F59JH8MX4uUD3yyddbOvg3WSq/gzPk58Rczzwn+XM8J3ADneY+ft+Jw FuSC0zr3etW9/+k0PnsEyAWVis00Q33zCFLJ5tysQODKoMEvkkP05fBT+3b8LIhfmN hAqjMF2R/5uiNxrr/a0D9x+X/A644ZV4iEySBaIlUKAJb1Yn9D3EZFoIIDIIcpztGr Ih3NH8i5EaHarLXQmuqq4icnmX9mZpAL9XWthfELywS6FzDaFgb6CRjF73kri5yIAK jhM7aVjWBLzmKniS2itUuItDHpY/9tVz+LS2FwAA3KBNdxcyIg4hnyg/ZKlFRbvUqv bOqQqo6iz7FhA== Received: from [10.0.0.30] ([73.83.213.54]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 256/256 bits) (Client did not present a certificate) by resomta-c2p-555954.sys.comcast.net with ESMTPSA id 0tWbugbUVWkiv0tWcum2Z4; Sat, 05 Apr 2025 02:44:51 +0000 Message-ID: <591a0d84-a74a-4d8e-bd40-04475eb5b457@comcast.net> Date: Fri, 4 Apr 2025 19:44:49 -0700 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: Samsung T7 external SSD support? To: Alexander Motin , freebsd-current@freebsd.org References: <39bd6092-4bd9-4086-b202-08b83b425fb5@comcast.net> <35d2361d-80e8-489a-bd9d-6c5ada5736b8@FreeBSD.org> Content-Language: en-US From: Steve Kargl In-Reply-To: <35d2361d-80e8-489a-bd9d-6c5ada5736b8@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4xfCGk0JUW90nhRESr9lc57Jry8/597OObkk7EPDq++Fx4+lCxALUrz3ObDO/rt8tjVhLFS47zotSQsX/HMOFNBqnkaSJupIw2WJYDB36e3gvSZM4AY1tT VNcP8AktS4wDX/E4TZJns3SYbhgmfuL1vJW6mBWGCDR615ZltSGR6Z//cAo8N6kr4KZyugXJxLSiRaatVF1X1Z8oaUrmetvNAzyxG3bUtGAH+eiU7LLV3/Kz 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:7922, ipnet:2001:558::/29, country:US] X-Rspamd-Queue-Id: 4ZV0F654Jnz3DWv X-Spamd-Bar: ---- On 4/4/25 19:28, Alexander Motin wrote: > On 04.04.2025 21:45, Steve Kargl wrote: >> Anyone using a Samsung T7 external SSD with FreeBSD current? >> >> If I plug the drive into a USB 2.0 port, I see >> >> usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage >> device Samsung PSSD T7 Shield (0x04e8:0x61fb) >> ugen0.2: at usbus0 >> umass0 on uhub1 >> umass0: on >> usbus0 >> umass0:  SCSI over Bulk-Only; quirks = 0x0100 >> umass0:5:0: Attached to scbus5 >> da0 at umass-sim0 bus 0 scbus5 target 0 lun 0 >> da0: Fixed Direct Access SPC-4 SCSI device >> da0: Serial Number S6NPNS0Y201077Y >> da0: 40.000MB/s transfers >> da0: 1907729MB (3907029168 512 byte sectors) >> da0: quirks=0x2 >> >> However, the SSD is supposedly a USB 3.2 gen 2 device with a ~1000 MBps >> read/write speed. >> >> When plugged into a USB 3.x port, I typically see >> >> ugen0.2: at usbus0 >> >> and the device is not listed with usbconfig.  Repeatedly, unplugging the >> ssd and re-plugging it into the USB 3.x port, I eventually get the >> above dmesg output.  Do I need a quirk for this SSD to get >> recognized?  Also, >> shouldn't it connect with faster transfer rate than 'da0: 40.0MB/s'? > > 40MB/s exactly means the device connected to USB2 controller or at least > at USB2 speed.  Considering that other times it does not connect at all, > I wonder if some signal quality issue or something else prevents it from > going proper USB3.  IIRC USB3 uses completely different wires in the > connector.  Also USB2 and USB3 can be handled by different controllers > with different drivers, so not detecting it still might be a software > issue, but I can't say much about that area. Thanks for confirming my suspension. I've tried two different cables. I have few more I can test. Unfortunately, I have to use a short USB 3.x extension cable as the port is on the motherboard under a table. -- steve From nobody Sat Apr 5 02:50: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 4ZV0MJ4Csxz5sqh3 for ; Sat, 05 Apr 2025 02:50:20 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (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 4ZV0MJ3bLXz3GCY for ; Sat, 05 Apr 2025 02:50:20 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x52c.google.com with SMTP id 4fb4d7f45d1cf-5e614da8615so5280651a12.1 for ; Fri, 04 Apr 2025 19:50:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1743821419; x=1744426219; 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=K+T3Di6tnIcZrx4fIOAlSq6lgZmtSVMaUQkN0UnDu5w=; b=Tja2csW+sjuQmgAvuPa28l9IxUQ+AoheY+zy6WJ+y5ABSWxlnNO2LOE4KSgc7eYusS Y86vQ+0akgXIgw9TD7KHh8mJdu+ZBbgGIY2OGWl3J9bHSmVTS8ZjbU4rFFbey12z4qAI o7nZP7c1ZKICRMZ76Y8N95NHMANI7+IURkBOIHNjhaAyufUpIGjjFi5LV/K4n6/eOCiK 4MllyZ484ZDlhPpMlF2etJJvFPJa3X3tMocU0sbkVGxDmCy1hzhzt6bU9qbTs9t4UZzu Nka1LyTDd9J07o+p8mn9P3VJi/ukJ1+gHdQP0vqkKZqJpWJSRgdeiOkFkaeXjH8HenGQ 1Zqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743821419; x=1744426219; 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=K+T3Di6tnIcZrx4fIOAlSq6lgZmtSVMaUQkN0UnDu5w=; b=EN83vo8mEwe5cXHyA2wYfoGFQ39z/6aanNvy2xDIpxH95dXtm1RCmlm2bJA0K24eFl oAloeAVCB57v80OiGIWgopUx2nILWBXO0OACF2tIJkcMfC1dewyDLZIRdiGFuo1XyZAa C+jozzkjaPd62OAIqY7L+u636qDcbEQD0hfVse70VRdNH9w7Kp2Z6UoX6VxMXAr/Exnu dSKcv70hVamQtE2uuwzwYRHt1ZPFa0q8uGPtsnqq5eC5oEb2cF9r80mKMHhiw2nyhAS8 s/etqQfgoAXX0t/VZ/Mmt6o7+Oko/8HfTYxlPIU7qIDzO0djvLLUqrwxLWBlBNCnD5uO hQZQ== X-Gm-Message-State: AOJu0YyHMg7EyKWRCRW4MQmMU0XU3YAAGIPAgrpfuCHx0igITQveMQ9h +wKHy0NhAcYDcaN+WIsMTR3IskbjsE801i6NVap08J5pt06tE9An+ilFy1I9GMNfe/l4YsEkzQp +1zjqY/HNrFTO4FW9ZMXXEHw6BjnqlqE= X-Gm-Gg: ASbGncsBO4jbD360EKuGXDxBdUvehDhoBVNSUYT3rgyEzKtp+drmgy619xdJd65KR0s lb/MUpZYGZLbZFhA4jubyq+tr6NOjjBpMv9e80AmfAXXns5guFTeXkyeVPg1D+0z3PATRMS4a/0 BnJ45wdZGhWl+at1hJw7Rn2PvUEq4b2hQx0iTv7OJmt9M6nvD9P6Qvfl94aw== X-Google-Smtp-Source: AGHT+IHjuix8YgrsHotpOiOCqP0ZJombom7rMVCiCto4UH/eh8wvG58IjMGDbIfTcShYZ5sLFC0e3jL2noHBYK5/hW4= X-Received: by 2002:a05:6402:5204:b0:5e0:8840:5032 with SMTP id 4fb4d7f45d1cf-5f08412c8d4mr7345580a12.3.1743821418920; Fri, 04 Apr 2025 19:50: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: <613d4907-6837-4cdb-abc5-86e53a6cce14@blastwave.org> In-Reply-To: <613d4907-6837-4cdb-abc5-86e53a6cce14@blastwave.org> From: Rick Macklem Date: Fri, 4 Apr 2025 19:50:08 -0700 X-Gm-Features: ATxdqUHKT-r8NW_xrOHS-o7wE6wEhof5m1nj2TZ1gaH6SKo-p8nMYeXD9gklztI Message-ID: Subject: Re: Heads Up: commit 2ec2ba7e232d just hit main 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: 4ZV0MJ3bLXz3GCY X-Spamd-Bar: ---- On Fri, Apr 4, 2025 at 9:08=E2=80=AFAM Dennis Clarke wrote: > > On 4/4/25 10:25, Rick Macklem wrote: > > On Fri, Apr 4, 2025 at 6:37=E2=80=AFAM Rick Macklem wrote: > >> > >> On Fri, Apr 4, 2025 at 1:48=E2=80=AFAM Dennis Clarke wrote: > >>> > . > . > . > >>> well ooops .... what was the idea here again ?? > >> Well, this has nothing to do with my recent commit. > >> > > Thus.... ooops. > > >> ZFS has always supported NFSv4 ACLs (and not POSIX draft ACLs) > >> on FreeBSD. (I actually am planning on a ZFS patch to add POSIX > >> draft ACL support, but I haven't even started to work on it. I do have > >> an IETF draft that adds POSIX draft ACL support to NFSv4.2.) > >> > >> If you look at the setfacl man page, it shows you how to set NFSv4 > >> ACLs. > > Oh, and to clarify it, ACLs are stored as "system" extended attributes, > > which this new syscall/KAPI does not access and, in general, anything > > else can be stored in extended attributes as well. > > > > So no easy way for a user/sysadmin to see what the big "Heads Up" did. The heads up was mainly for breaking builds. I did, but only for kernel con= figs without MAC, so only things like powerpc broke. kib@ fixed before I even noticed. (Serves me right for being an old guy tha= t took a bit of a nap.;-) So, as far as I know at this point, nothing has been broken by the patch, r= ick > > Dennis > > From nobody Sat Apr 5 03:25: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 4ZV18L4gMtz5st3l for ; Sat, 05 Apr 2025 03:25:54 +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 4ZV18J5WQPz3MPN for ; Sat, 05 Apr 2025 03:25:52 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b="IBGM/3Qw"; 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=1743823551; bh=sh02sRtzQNFcXU8azk026rSOBGN1tArifzY0FaLiGZQ=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=IBGM/3QwA/DSxX02mjE/jwX5l2uisUIbJ3CRs1MeVpHfydZ9ea8MRF1FtI6AnOCkSS1nLwJrR0W7R3X8dyUANsxijxRN5QH7ryI6c4g7QgPZIehHxv69RIhEogfqUPedUltrZT8p0cl0IC4TWmThtuSJXmymMNhvVhA4V5GquJeIe1OxRF2XU3aC1psfBl3DH7d3zpclC9ANU2Uvr2rbMWplNmwLgI+isr1td53Nw0/Ph5sy5jEW3B/m8Od1RIwzq8CSxD1hkQbJ2sjXrubUjprv3TJbqxvexjykIj4gVfX1bxCrmrIqwQMLBSx8/tSpdTxyrhFmFjj5ofW1zdsvIw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1743823551; bh=ym57eluI5pgGrjQadTyXsfHlgE1AimxAwFfYY8JLJhE=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=XQnfg6JIfZV4nDvm8FFJ9rjx0985mBxe/qShw8HT8UrvVi0P6VsKqt44BIUNzBb1P+WNex/QLhVKZXHBEy79tY3wM/nKdFXKBkJY7vicCXZA+BrZmw2Glp6HMoGjsCWkza1MpiCqdR76fVju0SdFGvlrasoMS737cdx8UT4wm7NqFF+BcSQiF+yzgpP3SoAUf6nxFQugeYjdkw/YrK18MyfV/3iBscbOQ0W+SASKEz8D1oMnoxDZjCDgOGau4rnmSoKyIOAczfeNYPEU9zqBBzhuYMSwPNuZmpySp1qYTMQ1dPW4iZLA0+8zEl4mhmzU16fNnQZQhqC28LuFahPUhA== X-YMail-OSG: nPD16QoVM1mBz.KSyQZ8NFiwFA3JlpYPaCkgZr_xLUPcTh4NDPp6Ps4QTZor3qB BuyPCjgd1wjYUO0ttRLrQbpG1AnR0XpiwDYGEYfmIQ3wx0NbOyYLS7uoHqlfekRGniYP8OLBOVSF s24rX_EI9CEKKif8mh6ODq9Uj7jFwNfnFJ0Ysrfb0dm241dvHWXRHot__Iq7malTruvGZJL6.Fok qxFHNY42qknr5GHaxWoeFCe5L95zWucpGq5n25bikxN.Btt7wxRdd_5Dkfd5YIQouarmsF4lgTdW F5Y6Bx7SnLDb.oUCGOUqsXw_0a0bUcU_uPX7TRwzFVhdCSuEf3sXaVquVEhh2w0JD6JD.0I2KOe3 .orMu7aHxtZ1_LrJorUqWfKX_k1mogzmIdJQgc260BxtT39lNcXZf8IDRA4gPFFlwvcjgC87Nykz jD0NKct5ZANgfrHUMwhk8oOqpYf8G5hhpFC6YBGeppNnPVE3E.BW0QOAq6Ep9EcArH9pzjKBSolv OFumfq1dwsJbZTJH9AhASiVT59XyNUk3eyQ.QsgC7Um0Q7WG9lAKYO0R4T1eY6LRIcmV9b6GhNKV IM26ocpmCDuBC5xuGhJOm0.E16Z7SucdIygxpqUvbzAwsWyyzuZaTVHN7kkAU_0YzGKnHNKaeJue IVvyO2NlbBUXym6GZjZAp.3TgF7U2pPgldidYJgdBAf6PsUJJDyaU.vx6OlEFEsOpSrEjhTJG00p d9LvkioS2CzjkFXjEs2kZwZ8g5wpYHlwKgF.tyP4Cy.vCBEX6oe3TGAHB1dp.Y6_RmMkAu5KC9vj YaUI4pGA9W12COOarUTMafgowO8WBh6cjT5fb4LH3FpFkAgqdmz.MQcDUluR3x0NuImtoeDBGWlu z8gsdkIl5Lt39GgiYwJlOZRJSAbFBiTH.Idn6dRcon969edUWrBOWGWo6wKRgeaw8kkM8gHgfE0c FfJboCDFknWAZCE7m6bxeuSE.GGWulRZtTQ8eJd_UjQI1sj_YChhPO.pqvuPsY9nLbNTkXkKjuia gELN9Gn2dEjkeiBunCWgmRUMm85QmnE47RGqYMMD6C7S2Jud9fe0mEg9eAU9HvQTljKjgWKnctIF eQzOZDRqOjedpnVII3DlkbjFwP_LJRqqfr7_N5fibSGQosHE_71nGUqrlCXSoeQ0fSUP_Po1b0L0 cE04okvLbFgsfjlhImFVID7BdQ.xkmrx6hoEfeaEHHpv6H1oLJOBlvDMFAakHtGC8EbgOHruhDCq OGgmYgozGcuZneHY1HbEJP2eD1ABLDvEyoM6W_fhy1EphWhZZE6vI_RflQI2fdRKOCCcJwjsu5_L 1LEkadh0uau2sQXnY0udZsM09dRPaBzBbth3P6xZFbD_eNCSs1_7cGFhEEUB1Ly1muntK_qp5er9 GGrnlfsC0UvTRT.kfG8.9_0mD8bo2miYMS9jplWsWsmSpshxzek1Mje13r.ckH78lsChuI_8ZIvV _idgjNnMJY2g8pZNKYbOm6PKDJ9TKgbV8y7kwfYox3lmcixHkGTNaCcVv61MYRSqvyYYAaedfD47 OILwyBJ9HcpGg4dMmzGjQM.tB_18NxoGYiSbvnE8_Hl39AsMolnOhi_VwXQTiTwBhLiQtsCBFEET SWX.NSb.LNTcLcWl.._7wddYtxs9d8zIKLYd9Dpi51vBG2gIOIldPH4Ibr7takpv6IIGHKo8MtRN q12BLtexHVHTeMyxLJsNnVGX2EoimWM9iJ.CUkfC04mHJWcS8LerZEzushedS_OTeWLdlyBn4nID uIXJ_WV5k.t7TEAeyXZlBnAQar4d15OHBosMVi2ASatT3JVwXqDIHHb71vF4wuML8k7vKOwa1k.5 ShxmDKgoPjM5154WUlgp2.nHylkzLjra1kU20s9wnGzihnilMeLcCoU3JIxdayT93kBHwG6NMlr_ fKf9U10RTSsT4G4IMn787tuSHzflSvFTvCXgk2HblfmHhNHE3GNbveZtCmzXvXmptEXlxfdur3Mk 4hJupVCTF6hu0adQ1HK9miFWbPMM6qUxmNhG1T3jkDM0J7DsNRLBY2Sb3c0579LpmFqdqAC8naW9 iYNpRNEtehGZPw_BNgMRP9jwXnmR5SG09kTUw98OYG8lYXH4HF1c2x7zpaEx6KfqFWNwmWW73BbM ctIJJMdgty_Muk72eH0i8ibgiVEL_ZxnEFrZFl0UsN1v2.pG8VbZnvV1NenKKPnua_nuDEgoMCgh lvc7kQP81h2MqpDyLWnU4bNLB8T0FDZLwEUscCIqHFE5_i7joHC189u2PI.csReAwQpRx5UIhR08 z X-Sonic-MF: X-Sonic-ID: 5f9dee45-ece4-40fd-86a9-d1c891e045da Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Sat, 5 Apr 2025 03:25:51 +0000 Received: by hermes--production-gq1-5c477bf655-cprz5 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 0351f8b89bbad179a76629d4549c7ac1; Sat, 05 Apr 2025 03:25:48 +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.500.181.1.5\)) Subject: Re: FYI: main-armv64-default bulk build times (ampere2) look to have grown significantly [...]; 142amd64-default (beefy22) as well Date: Fri, 4 Apr 2025 20:25:38 -0700 References: <8E2FBAD3-EF6F-4D99-A340-21F8FD19AE0F@yahoo.com> To: FreeBSD Current , FreeBSD Mailing List In-Reply-To: <8E2FBAD3-EF6F-4D99-A340-21F8FD19AE0F@yahoo.com> Message-Id: X-Mailer: Apple Mail (2.3826.500.181.1.5) X-Spamd-Result: default: False [-4.49 / 15.00]; RBL_SENDERSCORE_REPUT_9(-1.00)[98.137.64.84:from]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.992]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_FROM(0.00)[yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; FROM_HAS_DN(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.84:from]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.84:from] X-Rspamd-Queue-Id: 4ZV18J5WQPz3MPN X-Spamd-Bar: ---- On Apr 4, 2025, at 09:04, Mark Millard wrote: > Longest ever prior bulk build of main-arm64-default (HHH:MM:SS): = 171:50:51 (Host OSVERSION: 1500019) >=20 > On going bulk build: Built 11348 Remaining 23676 (HHH:MM:SS): = 85:57:28 >=20 > This suggests possibly more like 230+ Hrs for the completed build. >=20 >=20 > Now (0n going bulk build, first such): >=20 > Host OSVERSION: 1500035 > Jail OSVERSION: 1500035 >=20 > Previously (recent): >=20 > Host OSVERSION: 1500028 > Jail OSVERSION: 1500034 >=20 > (or before). Longest build time: 163:20:35 > That timing is for: >=20 > = https://pkg-status.freebsd.org/ampere2/build.html?mastername=3Dmain-arm64-= default&build=3Dp02dd5021d6f9_s717adecbbb5 >=20 >=20 > It might be appropriate to monitor: >=20 > = https://pkg-status.freebsd.org/ampere2/build.html?mastername=3Dmain-arm64-= default&build=3Dp25bf3a3260c7_s680d34896c3 >=20 >=20 > Note: https://pkg-status.freebsd.org/builds?type=3Dpackage&all=3D1 can = be > sorted to find the 171:50:51 that I list. I forgot to mention using searching by main-arm64 . > I''ll note that it was > for: >=20 > Host OSVERSION: 1500019 > Jail OSVERSION: 1500023 >=20 Sorting the list shown by (searching for beefy22): https://pkg-status.freebsd.org/builds?type=3Dpackage&all=3D1 by decreasing elapsed time shows that 142amd64-default has the top time by over 9 extra hours, despite building fewer packages: 58:51:19 for 142amd64-default 25bf3a3260c7 to reach the Remaining=3D=3D0 = crashed: Status, building 34744 packages 49:37:29 for 141amd64-default 182ff2d0ad1b to reach the Remaining=3D=3D0 = done: Status, building 36022 packages Note: For 58:51:19, the last job has "ended at Apr 3 11:48:00 UTC 2025" and the Started (UTC) column has "01 Apr 2025 01:02:20 GMT". So the "crashed:" part does not seem to have contributed much to the overall time. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Apr 5 03:56: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 4ZV1r44dRlz5svZ9 for ; Sat, 05 Apr 2025 03:56:52 +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 4ZV1r402GZz3TDK; Sat, 05 Apr 2025 03:56:51 +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 5353ubkT022245; Sat, 5 Apr 2025 12:56:37 +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=1743825397; bh=Lz3CKsm+q6bQLmXFC8BSMxV8nHFMsz2jnaaSEqSGptY=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=jvN3e4Ltjk4H3zZ6FjshKXyj/RGjO9zj76NzBnZ45ybwVbtLZlY2+GZUkcAPgFnw8 fgs05zmUou450drzyC2JvITS/YoumJU+oUsYEyx28wpcKahoUNhvsA2u0XXheQeYBX O2svGQW48WLEura3/8WdFSbASY1GFpMhZnCbGs0M= Date: Sat, 5 Apr 2025 12:56:36 +0900 From: Tomoaki AOKI To: Steve Kargl Cc: Alexander Motin , freebsd-current@freebsd.org Subject: Re: Samsung T7 external SSD support? Message-Id: <20250405125636.b078c4cdd3638a677af16494@dec.sakura.ne.jp> In-Reply-To: <591a0d84-a74a-4d8e-bd40-04475eb5b457@comcast.net> References: <39bd6092-4bd9-4086-b202-08b83b425fb5@comcast.net> <35d2361d-80e8-489a-bd9d-6c5ada5736b8@FreeBSD.org> <591a0d84-a74a-4d8e-bd40-04475eb5b457@comcast.net> 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=UTF-8 Content-Transfer-Encoding: 8bit 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: 4ZV1r402GZz3TDK X-Spamd-Bar: ---- On Fri, 4 Apr 2025 19:44:49 -0700 Steve Kargl wrote: > On 4/4/25 19:28, Alexander Motin wrote: > > On 04.04.2025 21:45, Steve Kargl wrote: > >> Anyone using a Samsung T7 external SSD with FreeBSD current? > >> > >> If I plug the drive into a USB 2.0 port, I see > >> > >> usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage > >> device Samsung PSSD T7 Shield (0x04e8:0x61fb) > >> ugen0.2: at usbus0 > >> umass0 on uhub1 > >> umass0: on > >> usbus0 > >> umass0:  SCSI over Bulk-Only; quirks = 0x0100 > >> umass0:5:0: Attached to scbus5 > >> da0 at umass-sim0 bus 0 scbus5 target 0 lun 0 > >> da0: Fixed Direct Access SPC-4 SCSI device > >> da0: Serial Number S6NPNS0Y201077Y > >> da0: 40.000MB/s transfers > >> da0: 1907729MB (3907029168 512 byte sectors) > >> da0: quirks=0x2 > >> > >> However, the SSD is supposedly a USB 3.2 gen 2 device with a ~1000 MBps > >> read/write speed. > >> > >> When plugged into a USB 3.x port, I typically see > >> > >> ugen0.2: at usbus0 > >> > >> and the device is not listed with usbconfig.  Repeatedly, unplugging the > >> ssd and re-plugging it into the USB 3.x port, I eventually get the > >> above dmesg output.  Do I need a quirk for this SSD to get > >> recognized?  Also, > >> shouldn't it connect with faster transfer rate than 'da0: 40.0MB/s'? > > > > 40MB/s exactly means the device connected to USB2 controller or at least > > at USB2 speed.  Considering that other times it does not connect at all, > > I wonder if some signal quality issue or something else prevents it from > > going proper USB3.  IIRC USB3 uses completely different wires in the > > connector.  Also USB2 and USB3 can be handled by different controllers > > with different drivers, so not detecting it still might be a software > > issue, but I can't say much about that area. > > Thanks for confirming my suspension. > > I've tried two different cables. I have few more I can test. > Unfortunately, I have to use a short USB 3.x extension cable > as the port is on the motherboard under a table. > > -- > steve Another unwanted possibility would be that controller mimic'ing SCSI (As reported being "umass0:  SCSI over Bulk-Only") is reporting as if it's U2 or UW SCSI device. https://en.wikipedia.org/wiki/SCSI https://en.wikipedia.org/wiki/SCSI -- Tomoaki AOKI From nobody Sat Apr 5 03:57: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 4ZV1sJ3JbSz5svnp for ; Sat, 05 Apr 2025 03:57:56 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-22.consmr.mail.gq1.yahoo.com (sonic309-22.consmr.mail.gq1.yahoo.com [98.137.65.148]) (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 4ZV1sJ1BpZz3VMv for ; Sat, 05 Apr 2025 03:57:56 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b="J3Xeot8/"; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1743825470; bh=Jwlc/+IWBmxVcV1/vBfWD6YVW9emuVdimqNGlyRWN9U=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=J3Xeot8/qZB/cejykPG8r4LFR25n148QrdjQUBCqbqqjQTBfolhIVpKLFtWm8BBOPgwoQV0qoLtUxHSWN0L2hftbixFN9J9nRRzf+1vJ1tPf8yHFPCTxFdrdFAYy1Sh/T7Sg2Lv9MjJkh8Rl0nVSq2M6pIE7bIOoAD88pVkyUaSyfQIAYADE+sa+Wh/xdfQc9IQbI96JeAqJV+rolCtDU8VEE2yNSdUfby/w3rDrTHw7QspDPYKdCkVkaw+yUoTJ3VEN/kzIjKfi7EeGASJ0T+AWAoTn76kkjdUvnyDjjNyN74a4JZJoQ8lzm/sliR6RwURaLrWOOk2aFMdgZgV2IA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1743825470; bh=OnXKSkvzz06SdNN4EibZlI4skuYOUmWPyHqdL4PTXIG=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=eAEqT8/+5uo0eS9mMwHBIqq7RFMU+eTFdk1/0fl7qf2XFoawZqBL4bob8d1kRRnSIu3go2xmrgU6N/5Tyn+VKa1SSfxM+xjgaIs0dR+XXuT3ZlLqFXERCLKv/JKkNP5zJ7mXrqMIrZ0wJhDj7NGE5K6Fe0NCWCBeS6+SMPHXoD57o0/C8fTMWSo7qt5hvzSG+/HuBsRMTvKsHhIYTLt9DYMn02injS8QoEL1dwSohOXtXDNkZe77JOmbbMrj1bRXTu/OBGK5MZDwHtfsBx8HPJ6MG1t2WghsmfGfr56y8glqBqmckO1wGwiLrrYH7PNkMWquI1wVSXLZQNFP0ji6oA== X-YMail-OSG: p64yUygVM1kFcHtX5wlozNR9jqzp._lPywUpERw6eWvSXt_2ilJ3R1VAq0kQ27k apVFnFUHnQpPXvMmfsfnG636dvnsbrl5ahSkOtJfwGE2VRcvEMUZw.gMCxqg5YiuWm5B3goNRZKM gHKPs5bw6nI9XizT42zmCsqIskbmn9_g0hW30kLrDcAIAglEP9crAca5wkG.ST2KhPnbvKaJFCL. EoxEvfTanbgu2NntgHIQxZQwhvbNZK0aki_RLMnuH2b3S0guLLuVcKTL_0wm.cGUp7NYgIrQszP3 vbSqh1vWh.QeWWfSFkU.UEKNUmpvHF4Ugw8D97PpcDiR.uHWooPmZkxnU3m_1bjytyQ9QHgf9xyg O5a9tlX0wYVhfTrKExAQgwU9q1BnDwKiPE4B7WlgONYZlap7E.yM3ZffWKU7ygigCJBbr8n8Z8gK ejdwYWb66ZFvZNBX8mMfGKjEaeFNv2RMbPSXgSA2lS_18C4AOm05f0OId9sPtqL.jdJFcAGOQO8D gkZZZyn_VaB9xfSu73_cSmCRcl6P3F.oIkhVuuZvWN.Z1Qj3TZ2xSjLEOPcMrNUIiyawf17seQib SDHOXSvCc8KwLi9ILHnGhTzdo83p_u_qEQs8jW4J7U4fa.09Lc0STfKi_m.438tQ6C_sDsQKv0DH uglqPBEWQvN_rAzjBDAK7ZS..RqPWWs8VPLa7f9NRIMLJ9Bm83U0NwfV0pzGY5qVSirxM2VEXres PjmHLua5e7e6t.4uefS33ibrKTURRaUfnZ2ToplrVD17RcIResT0whrju4b2UKxa.zt3Tjk5ZIXg 0yccGoQFi6wIoQ5s3dehuDl0ifJgyfuDnDb1N9i2nO2qusIfQJnL9tzQorNmBTzkUswHPg6bVCwk a2JvSV2WU8LLXTaOii4Omd3pg2HU9LpjGhF.s.qDY3PKPIjhZ08CVGZob83MndA8vUIScQ4UVPYZ ZBfpUyQhmFb7FrAaMRoypcorgug4DTQ8451xtgYyRZ3CPGAgghwa6s.9Skeu8vmGHa21xinbFlxf YPQf4HzPLe_uIMjcq7L56Mpor8cmB.JWJA1ZmJOWJ_4PJOHidKrKz1a.iTYK8QHdk03ADsZr2giR 5F1czTwdng4wMLMM83gf1xfb3w08SffM2qPWJHicd4mLe2jOQJZlBA15o3C53bxG1VV5CUiLKT0g xg.oWmWT3THXlaYezG_40h_Zq86QZP6WV2bEvN26svCMD2UmuZBDZp83abCBHJT4xOvJtMneNsOn fxa3E2Olvz0GF4hSsOKatyc_oNnNdgfWDckCJzQ431FfNS.QYTdLRhboUlwHS3Qk2KzdrpkIgvoo lYo_jhuOqb2k3YMzzeb6KGCA3ZjPcNL104zkwfFOrD_SsWUIm_Lfq5b8xyangmtaINfxy.xQ1OIC p8CmxTUpuk4PadhIXWQuH_dldTdMvJGGc5XOC3jVF4oAUi8YjLG__u2DreH8ANK_6tGoFZBGpNuy ePRmTpSqJtIdsvNqPLZn2YCQeqRD9eQCLJSh70ykU1RK9S7m5eJIc2VQ240bM5_PF2jHzi3mmjtm CKhGyQzp2KWrzTsrPraRscN6g4uCkqdVgS_CeuZh3GXc3H86siGh0ovIFHZ9aQf3Rg.QOmU7f31e 3Bo6UZ7AlMNYtkvOMR285OmPA59WxoxxjzThFNZoX.demXs5f0i9XX2BmzvYTZrrN4c9oXlKIVSj mJYLThbhTaa1ZsRAYgXHIzVNTeHtG_roqjRwwWb6t8iIIynUu0O71ak9m.qBg.bjmjnfYz0Yjur3 kjXxZICoIF3NeRWCTJQwoggZcKhMM1.UdzOMf.odVuSLtd3OKDzxpUBOFrhq28zV.s33Kcs3_x6P pVBayOQlbv2kV2Rc_NFqpYa9uucjQuKIiOipUhGrb5AUbkceX6CFi0CQVP8ev0RWpaA71Mts5D2h YGRM76NAQUwfRzfuxPQveFFhYQQtl3dUAYL9jlTGaa9qe6A7E4CeFW3hiWb6Oa2Tget8curm_DdF LFieZvRdTFu3rTzsYkUpM9mv5XFYie9B6D5ox2BAMR8ZKYfljppzLWX9tZaEXcn2yqY0DSwb5AIf YrETuE1s0fEqWk7Orcq5y1Y5Gxy1loHQF4czcxxpW89vEd3eQ3XB6FcRMxblHJ4il0gcNBsDHHCS g_77cIpZghxJcevPyfVotCBApRJgQKvV0RpIY6lMz3yI5AODPfOHfbSQks77Mw.3sYr2YyBAW6Ev .S8_FWYqC7l90tgL1Vl4IHEwpRjfZqjbG X-Sonic-MF: X-Sonic-ID: a29379ae-c06e-4be8-b9fd-5e841b87cc13 Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Sat, 5 Apr 2025 03:57:50 +0000 Received: by hermes--production-gq1-5c477bf655-7mdkj (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID ca8911315627e4bdd94dc723b8c14d76; Sat, 05 Apr 2025 03:57:47 +0000 (UTC) Content-Type: text/plain; charset=us-ascii 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.500.181.1.5\)) Subject: Re: FYI: main-armv64-default bulk build times (ampere2) look to have grown significantly [...]; 142amd64-default (beefy22) as well; more, including 72 hrs+ longer for main-amd64-default (beefy18) From: Mark Millard In-Reply-To: Date: Fri, 4 Apr 2025 20:57:37 -0700 Cc: Konstantin Belousov , Warner Losh , Dennis Clarke Content-Transfer-Encoding: quoted-printable Message-Id: References: <8E2FBAD3-EF6F-4D99-A340-21F8FD19AE0F@yahoo.com> To: FreeBSD Current , FreeBSD Mailing List X-Mailer: Apple Mail (2.3826.500.181.1.5) X-Spamd-Result: default: False [-4.47 / 15.00]; RBL_SENDERSCORE_REPUT_9(-1.00)[98.137.65.148:from]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.97)[-0.967]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; TO_DN_ALL(0.00)[]; ARC_NA(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.148:from]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.148:from]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] X-Rspamd-Queue-Id: 4ZV1sJ1BpZz3VMv X-Spamd-Bar: ---- [Note: The new main-amd64 (beefy18) example reported is still building but has taken over 72 hrs longer than any other prior example. There is a major performance change involved compared to builds started before April. Slower hardware makes that more obvious than the fastest hardware does.] On Apr 4, 2025, at 20:25, Mark Millard wrote: > On Apr 4, 2025, at 09:04, Mark Millard wrote: >=20 >=20 >> Longest ever prior bulk build of main-arm64-default (HHH:MM:SS): = 171:50:51 (Host OSVERSION: 1500019) >>=20 >> On going bulk build: Built 11348 Remaining 23676 (HHH:MM:SS): = 85:57:28 >>=20 >> This suggests possibly more like 230+ Hrs for the completed build. >>=20 >>=20 >> Now (0n going bulk build, first such): >>=20 >> Host OSVERSION: 1500035 >> Jail OSVERSION: 1500035 >>=20 >> Previously (recent): >>=20 >> Host OSVERSION: 1500028 >> Jail OSVERSION: 1500034 >>=20 >> (or before). Longest build time: 163:20:35 >> That timing is for: >>=20 >> = https://pkg-status.freebsd.org/ampere2/build.html?mastername=3Dmain-arm64-= default&build=3Dp02dd5021d6f9_s717adecbbb5 >>=20 >>=20 >> It might be appropriate to monitor: >>=20 >> = https://pkg-status.freebsd.org/ampere2/build.html?mastername=3Dmain-arm64-= default&build=3Dp25bf3a3260c7_s680d34896c3 >>=20 >>=20 >> Note: https://pkg-status.freebsd.org/builds?type=3Dpackage&all=3D1 = can be >> sorted to find the 171:50:51 that I list. >=20 > I forgot to mention using searching by main-arm64 . >=20 >> I''ll note that it was >> for: >>=20 >> Host OSVERSION: 1500019 >> Jail OSVERSION: 1500023 >>=20 >=20 > Sorting the list shown by (searching for beefy22): >=20 > https://pkg-status.freebsd.org/builds?type=3Dpackage&all=3D1 >=20 > by decreasing elapsed time shows that 142amd64-default has > the top time by over 9 extra hours, despite building fewer > packages: >=20 > 58:51:19 for 142amd64-default 25bf3a3260c7 to reach the Remaining=3D=3D0= crashed: Status, building 34744 packages > 49:37:29 for 141amd64-default 182ff2d0ad1b to reach the Remaining=3D=3D0= done: Status, building 36022 packages >=20 > Note: > For 58:51:19, the last job has "ended at Apr 3 11:48:00 UTC 2025" > and the Started (UTC) column has "01 Apr 2025 01:02:20 GMT". So the > "crashed:" part does not seem to have contributed much to the > overall time. >=20 It happens for 142i386-default (beefy21) as well, this time taking somewhat over 10 hrs more for a more similar number of packages: 50:40:16 for 142i386-default 25bf3a3260c7 to reach the Remaining=3D=3D0 = done: Status, building 34415 packages 40:22:44 for 141i386-default 35e33b5b9186 to reach the Remaining=3D=3D0 = done: Status, building 34578 packages It happens for main-amd64-default (beefy18) as well, so far taking 72 hrs+ longer but not yet having finished building packages: 168:11:10 for main-amd64-default pad39cc941617_s7a490725045, building = 26636 packages so far, 9338 Remaining 96:28:10 for main-amd64-default p9229caa5b2ac_s780a4667bbd, building = 35771 packages, 0 Remaining =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Apr 5 04:58: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 4ZV3CD229fz5t0RC for ; Sat, 05 Apr 2025 04:58:32 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-25.consmr.mail.gq1.yahoo.com (sonic312-25.consmr.mail.gq1.yahoo.com [98.137.69.206]) (using TLSv1.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 4ZV3CC6Fssz3f4y for ; Sat, 05 Apr 2025 04:58:31 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=mAyGZc2R; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1743829105; bh=XpCFdUPtgC5dNDECAytYDTfKQjf1ulp+Egf4n48pKfo=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=mAyGZc2RMCjuxMDN3Fc2wE2iJrJ4bKANppXF808gJjzCRfwTiFrPGwlxPe5XWS0odho0IwpMls6rXkYKrOVuN93wtgLLC+zi35m8u9zd0qPlnLYwxuE5dk/kJsO6eLQH4UNVe99F6NYOI5SRRivMOcsniodck0wEUzImOqCYnSMIhcuuQBC3sLp5zZN1phcMAf0BCsm1ikWB6w6+bua3Q1NjRVW24ZetgzVKt7T94gyS7oYDUsU5+NLFn8Jta9T8YubhQiFiaCA8sgTKhSDS66Vn9L76/t1Vb69PndpfU6Qd4OSdOegPefjDGCQnKm5aRIYTfLdBoHJMHJsUqtg6Mw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1743829105; bh=XlMAg5SY9RfEi1QpyKDKkG+oY/1JKLW01f0yEYoSqiR=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=Eb+53s9H/P36pmh6+fanNOTRyHzpnPeNIOEIGY3rdnjLkN+zfs4peB+aj0o5vToy5jU7PD5oHwawOuE9HhFUH97bKPaPMtpjZ+rPM8j9PElINgLfpgbZm3EPMM9uAMpUymNx/n7V9mu71pyMsIkr5QT2jYn+LgGfsBFO8HfMR71dECD3UBDUt1g9x42SMkXBYROntJwTT0XFw/qa4c01O1WZ/KbWuZ9T58xrXO8LYB0MmfMKSnPjZfRjZ5sKkl23ynbgd8jpku5DUd5WBIQhVaFdZZtfqjbm8v6JBNCr8hPLn3vUcrY0rb0Nzm5XRnuPg29ueKCANgk3MKhlOu+CQg== X-YMail-OSG: SVobrCgVM1mQUj6AwEeQbPhA0Di8Lw6.WBr38idsvEUo55ka.p.BzQatOOmr_YU y0EhlZ64pWs0n9OUprn2wf7plfuoOvr0aqs1Ln.byOxjf1JNehPyqL6n8.uclkk57sh2lxqLJyu. _fYMoLYeAjZyyBynIMs4ndcZIo.VqTATswBS2.x10rbc31AwY7O1Q1Ox6msUmQZFc.F.F2scupXa pee8Vk79pNrG.1p6707qxXccJ7NRa4cmjbP9W3eG4uBIe2y5L4Naju9LTFAoYryARfDokgzgVghA NJ.IxkbFgSFr2l8VdgyJvh02CG6fCp1H3t2Xinh_L585NvN2dkdYyZLvTrYwGJJ.39k2OsSzAQBq pn6UI78IGxEib3cqnjPjnK3.704O5aN790fgmn4ZDI2jFW7AnTfrTTP0EzBu7fV3GATrFdwCpjLr U2u7D1.kC9hyJ6l3IIOHSM1rWmlg3O6yPYbyagOAyz00sZUDoJ0l_Yqa72PaPWZqRLRtKmLYqsG_ ompL0.KYodkAGE08DQJpLPAL8B0_FF016Aucj28tLFmzZ_QPKq8cSQQ66CiJ.02.GEXGT8vAuW2K hMNUoceIWVMAit7mLpMkIdfNd89eAuLSCp2ZOwcZw4ahLODljydQ_qlpbR8HEImaarj3bZxeiU6l ll03hua4uyg3kD1Af6U9mOO9rRR8pvhgo7jQB_AVAX0PzmfdPKEU8XAWSX.YhvMoGpShKloOub4Q b9wO9MaDdOK5wDeSuFQJvdJZ6LrL6FlnFHRMVYoJ41p9_1g4bJ2.A7b1J3CMFnRSWLy7zHLT8LU5 SYglT3BOlQQ0Pb7ZZrlQqIwzVw1Cuzj9zS8CVJN2Ppl05wTxugMTqJMByy6zbhvUuJGrfI31LIRF ZaIiL3YSSAI4j9TbfhavFWVSjOqf3HvmI945XSss7.LUNsAusAIt5GR9XlO1HzYuAGMfNWToWkd. b7Vjok95NpctOLW9BInu3yLEqwe0KyrKtfzJGoWqnu5oTSFxSdj3UEMcRPzLVg6QE3u28STsIgZI qd1JYVBGdV90h26T.4poZ63C_g2HIVDM8Z4ah9S9s6bbklqpdLOLKp4POwcWC1o.n65feETdUs6R .wHlt9VOqQO8zsQflcwnFbXMI4NQVZdJnAK4fA3D2rK4k55jj5q1RRUWwHvI6E5xh6u5MBOV.gkd kDeg0G.uCXOoHl23npBU2s84rp32JOi5neySSryNco1h_9yx9sy2CSyGtizV9CebraBX.3xbKa8y AcN6KX473temUfziRkBKfeExloa8W5FIe5xaPBtqDfQOEzanwuIKGr9qNe4r.K3M.LGJnOsIqvsq JgUD05FCvMHQqxF7pV0i1i5PXHW.c8LLypG6VkIkdjZz6.PhAFGqB.lFrc1st1jTFXI3EcAeyhYj S2h51t6sA.hQrCA0IPsXAQ8E8J4tBAGSRLoIyRJnuRwPk2i8hVqbL3XB__NAkYIkC.mVxMtC0FNT moPBJ02_YBI7gEqmby8lQUlTKq7GEnATpYkYtk98hKH26sPBuUc6K2mWTo.xEGvwqW2kYOdbzhEl 940XF50Okng5l20.3GfNkftnhwA0aeiFCsYraXcTHbc.BK1zJeqXnbaFUWXbEzeATocNVuu1I4lO 8G5UJcR9uS1bsRfvI3EOeZBvzG81B23lIzZGpWdJLgYrCJ9qg6J.nySQPY0xfSCpXyBDErgCldhG sSL2V3Fv0EHrizS9U5GS_ahZyfja9f9.1YDV_WcUy3EhkbHoxRdNzibnq8JdJg6dEfsO_pStpSuA rKm7vwOQ6Xv32hycrbRFw3MYDC0AXXbHouyaz8WiWcKsdBUn0LWArD2ZzSQqAa6AySKIWr0iHoug zDc8UJFWD0M6lnXDi4TDB5k6kq.JuQJPEvDEvt8yw8n.Y9v8KCS3JTHfWfhhE34wkB3hsg3ZprNY qQUsQiY26zQsqbcLco2E.IZH9tzkKRy_RLazUcVr_WI4umVyQPujhlQJXpjg5Tw_yWPXtzBf9RzL orCw2TaWYNA9svO5_nUk3hc744gFTutxYwgRJZ5kJSf79UAVoALaaUYGWe71RS.s23DpMjLCy7yo wIXEdMYAMc1ZMwJDRS.DExmgliAa.OEEfWop2SzYWskZh8cZ0ECoIWWMI.7fKfH.0KUSrrAoc5IQ IEObBTit42IXQsV0JNANfVcAXU3ZcE1VxaBqpTq9kG.M3N1MF4s89SJIx2Li5ijhAJ7hF7gR_1q6 dk96KXDGYwLc.ldmhMNr6JGHiI9PxijIh9mY- X-Sonic-MF: X-Sonic-ID: ddfe6bc2-4895-4558-88d8-90f639c0024b Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Sat, 5 Apr 2025 04:58:25 +0000 Received: by hermes--production-gq1-5c477bf655-tmnlx (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 28a42cdd662b3846277e14597f82750c; Sat, 05 Apr 2025 04:58:23 +0000 (UTC) Content-Type: text/plain; charset=us-ascii 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.500.181.1.5\)) Subject: UPDATE: pkg 2.1.0 looks to be making official bulk builds of packages take much longer From: Mark Millard In-Reply-To: Date: Fri, 4 Apr 2025 21:58:12 -0700 Cc: Konstantin Belousov , Warner Losh , Dennis Clarke Content-Transfer-Encoding: 7bit Message-Id: References: <8E2FBAD3-EF6F-4D99-A340-21F8FD19AE0F@yahoo.com> To: FreeBSD Current , FreeBSD Mailing List , Baptiste Daroussin X-Mailer: Apple Mail (2.3826.500.181.1.5) X-Spamd-Result: default: False [-4.29 / 15.00]; RBL_SENDERSCORE_REPUT_9(-1.00)[98.137.69.206:from]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.79)[-0.788]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; TO_DN_ALL(0.00)[]; ARC_NA(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; DKIM_TRACE(0.00)[yahoo.com:+]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.206:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.206:from]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_FIVE(0.00)[6] X-Rspamd-Queue-Id: 4ZV3CC6Fssz3f4y X-Spamd-Bar: ---- [This is an update of earlier notes, now that I've noticed what is different for the contexts that not seeing larger time frames in the Mar-29/Apr-01 bulk build starts of official package builds.] The context here is the official bulk builds started 2025-Mar-29 (beefy 17 and beefy18) or 2025-Apr-01 . pkg 1.21.3 was in use on beefy 19 and beefy20. These did not get the significantly longer time frames. pkg 2.1.0 was(/is) in use on: (beefy17 and beefy18 are significantly slower hardware than beefy21 and beefy22) beefy17 main-i386 168:11:08 vs. prior maximum 74:19:29 beefy18 main-amd64 168:11:10+ (so far) vs. prior maximum 96:28:10 (beefy18 still has 9338 Remaining and still has status parallel_build:) beefy21 142i386 50:40:16 vs. prior maximum 40:22:44 [141i386] beefy22 142amd64 58:51:19 vs. prior maximum 49:37:29 [141amd64] Note that beefy17 took around 94 hrs longer, more than doubling the time. ampere2 main-arm64 is somewhat over 1/3 of the way along but also looks to likely have a much longer overall time frame. Note that beefy17 and beefy18 had/has: (has large time changes) Host OSVERSION: 1500028 Jail OSVERSION: 1500035 beefy19, beefy20, beefy21, and beefy22 had: (mix of little vs. large time changes) Host OSVERSION: 1500035 Jail OSVERSION: 1402000 ampere2's main-arm64 has: (has large time changes) Host OSVERSION: 1500035 Jail OSVERSION: 1500035 So: The new Host 1500035 use is not the cause. Nor is Jail 1402000 . === Mark Millard marklmi at yahoo.com From nobody Sat Apr 5 05:47: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 4ZV4HT0csYz5t38l for ; Sat, 05 Apr 2025 05:47:17 +0000 (UTC) (envelope-from kargls@comcast.net) Received: from resqmta-c2p-569298.sys.comcast.net (resqmta-c2p-569298.sys.comcast.net [IPv6:2001:558:fd00:56::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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZV4HR3hVTz3myp for ; Sat, 05 Apr 2025 05:47:15 +0000 (UTC) (envelope-from kargls@comcast.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=comcast.net header.s=20190202a header.b=YTSUmWeW; dmarc=pass (policy=quarantine) header.from=comcast.net; spf=pass (mx1.freebsd.org: domain of kargls@comcast.net designates 2001:558:fd00:56::4 as permitted sender) smtp.mailfrom=kargls@comcast.net Received: from resomta-c2p-555483.sys.comcast.net ([96.102.18.238]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 256/256 bits) (Client did not present a certificate) by resqmta-c2p-569298.sys.comcast.net with ESMTPS id 0wN2uhGPtQ3gc0wN7uZUfc; Sat, 05 Apr 2025 05:47:13 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=20190202a; t=1743832033; bh=SNUfkmd5q42RorqV034uKTLF1qDNcP79wgaY5LuX8ho=; h=Received:Received:Message-ID:Date:MIME-Version:Subject:To:From: Content-Type:Xfinity-Spam-Result; b=YTSUmWeWFXRA53p83HRDDEWjrC4+FJr+ANqeuRk/tS+AfW9E51MTv2U6Ruuu4arUJ ChZvDUThJ321W4E48ZAG4weOpkTf7osV/zVfRGrNIFkdcg9n5KIddzoVOn04IZF0LO +a6SbdkpWPiNSw3uhT+m1GKYwMHDpd43B5pswnpi8T8fw78ekx16AwGSHs8NcxawhE bL7lYJ5mqN9MBapS+LVaf32SRXQNAjWxO7NeimmDNaST/QrFdpJZG00TvtVUUP2Kn6 yQPAD1uRLL+aqux5XfCAOPT9F7hh4g8Aw8Ch/KuvK+4+hUl0o8UwK09DYVQ/gh39FV OqEkiLnZh1Q8w== Received: from [10.0.0.30] ([73.83.213.54]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 256/256 bits) (Client did not present a certificate) by resomta-c2p-555483.sys.comcast.net with ESMTPSA id 0wN6uTwWHCC1I0wN7uRdNF; Sat, 05 Apr 2025 05:47:13 +0000 Message-ID: Date: Fri, 4 Apr 2025 22:47:12 -0700 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: Samsung T7 external SSD support? To: freebsd-current@freebsd.org References: <39bd6092-4bd9-4086-b202-08b83b425fb5@comcast.net> <35d2361d-80e8-489a-bd9d-6c5ada5736b8@FreeBSD.org> <591a0d84-a74a-4d8e-bd40-04475eb5b457@comcast.net> Content-Language: en-US From: Steve Kargl In-Reply-To: <591a0d84-a74a-4d8e-bd40-04475eb5b457@comcast.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4xfPt6huAoUj6VWDePiRPAB9+C2gxpYJfPfSDxYFWV1ql7eJsScxGkedbnazW1NHpCab65VvSrz1s9MYKtxJx50mxo/gTGWw8+uEB+6Amx81cflETaLUTe Fjk8t4YF2//8L//cL3MmOYNFmbKF+h7ZmQwJJfo4LuhZRD4ZpxKlZlvrt2lZmqW/FUje1KpvlyneGw== X-Spamd-Result: default: False [1.50 / 15.00]; HFILTER_HELO_5(3.00)[resqmta-c2p-569298.sys.comcast.net]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-0.998]; DMARC_POLICY_ALLOW(-0.50)[comcast.net,quarantine]; NEURAL_SPAM_SHORT(0.50)[0.497]; R_DKIM_ALLOW(-0.20)[comcast.net:s=20190202a]; R_SPF_ALLOW(-0.20)[+ip6:2001:558:fd00:56::/64]; MIME_GOOD(-0.10)[text/plain]; DWL_DNSWL_NONE(0.00)[comcast.net:dkim]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FREEMAIL_FROM(0.00)[comcast.net]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[comcast.net:+]; FREEMAIL_ENVFROM(0.00)[comcast.net]; TO_DN_NONE(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:7922, ipnet:2001:558::/29, country:US]; RCVD_IN_DNSWL_NONE(0.00)[2001:558:fd00:56::4:from] X-Rspamd-Queue-Id: 4ZV4HR3hVTz3myp X-Spamd-Bar: + On 4/4/25 19:44, Steve Kargl wrote: > On 4/4/25 19:28, Alexander Motin wrote: >> On 04.04.2025 21:45, Steve Kargl wrote: >>> Anyone using a Samsung T7 external SSD with FreeBSD current? >>> >>> If I plug the drive into a USB 2.0 port, I see >>> >>> usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage >>> device Samsung PSSD T7 Shield (0x04e8:0x61fb) >>> ugen0.2: at usbus0 >>> umass0 on uhub1 >>> umass0: >>> on usbus0 >>> umass0:  SCSI over Bulk-Only; quirks = 0x0100 >>> umass0:5:0: Attached to scbus5 >>> da0 at umass-sim0 bus 0 scbus5 target 0 lun 0 >>> da0: Fixed Direct Access SPC-4 SCSI device >>> da0: Serial Number S6NPNS0Y201077Y >>> da0: 40.000MB/s transfers >>> da0: 1907729MB (3907029168 512 byte sectors) >>> da0: quirks=0x2 >>> >>> However, the SSD is supposedly a USB 3.2 gen 2 device with a ~1000 MBps >>> read/write speed. >>> >>> When plugged into a USB 3.x port, I typically see >>> >>> ugen0.2: at usbus0 >>> >>> and the device is not listed with usbconfig.  Repeatedly, unplugging the >>> ssd and re-plugging it into the USB 3.x port, I eventually get the >>> above dmesg output.  Do I need a quirk for this SSD to get >>> recognized?  Also, >>> shouldn't it connect with faster transfer rate than 'da0: 40.0MB/s'? >> >> 40MB/s exactly means the device connected to USB2 controller or at >> least at USB2 speed.  Considering that other times it does not connect >> at all, I wonder if some signal quality issue or something else >> prevents it from going proper USB3.  IIRC USB3 uses completely >> different wires in the connector.  Also USB2 and USB3 can be handled >> by different controllers with different drivers, so not detecting it >> still might be a software issue, but I can't say much about that area. > > Thanks for confirming my suspension. > > I've tried two different cables.  I have few more I can test. > Unfortunately, I have to use a short USB 3.x extension cable > as the port is on the motherboard under a table. > Climbing under the table and plugging directly into the motherboard gives usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage device Samsung PSSD T7 Shield (0x04e8:0x61fb) ugen2.2: at usbus2 umass0 on uhub0 umass0: on usbus2 umass0: SCSI over Bulk-Only; quirks = 0x0100 umass0:5:0: Attached to scbus5 da0 at umass-sim0 bus 0 scbus5 target 0 lun 0 da0: Fixed Direct Access SPC-4 SCSI device da0: Serial Number S6NPNS0Y201077Y da0: 400.000MB/s transfers da0: 1907729MB (3907029168 512 byte sectors) da0: quirks=0x2 which is what I expected. So, the extension cable seems to be an issue. -- steve From nobody Sat Apr 5 06:18:52 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 4ZV5060vBnz5t58r for ; Sat, 05 Apr 2025 06:19:02 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZV5055qDGz3rSF for ; Sat, 05 Apr 2025 06:19:01 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Authentication-Results: mx1.freebsd.org; none Received: from critter.freebsd.dk (unknown [192.168.55.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by phk.freebsd.dk (Postfix) with ESMTPS id 1B3E78928F; Sat, 05 Apr 2025 06:18:53 +0000 (UTC) Received: (from phk@localhost) by critter.freebsd.dk (8.18.1/8.16.1/Submit) id 5356IqqY009260; Sat, 5 Apr 2025 06:18:52 GMT (envelope-from phk) Message-Id: <202504050618.5356IqqY009260@critter.freebsd.dk> To: Steve Kargl cc: freebsd-current@freebsd.org Subject: Re: Samsung T7 external SSD support? In-reply-to: From: "Poul-Henning Kamp" References: <39bd6092-4bd9-4086-b202-08b83b425fb5@comcast.net> <35d2361d-80e8-489a-bd9d-6c5ada5736b8@FreeBSD.org> <591a0d84-a74a-4d8e-bd40-04475eb5b457@comcast.net> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <9258.1743833932.1@critter.freebsd.dk> Date: Sat, 05 Apr 2025 06:18:52 +0000 X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU] X-Rspamd-Queue-Id: 4ZV5055qDGz3rSF X-Spamd-Bar: ---- -------- Steve Kargl writes: > which is what I expected. So, the extension cable seems to be an issue. USB-C is objectively an amazing feat of data transmission, and there is no margin for shoddy cables. This is the insides of a USB-C cable: https://opencircuitsbook.com/#outtake-28 (The "Open Circuits" book is highly recommeded!) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From nobody Sat Apr 5 07:09: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 4ZV66x4vYYz5rQMG for ; Sat, 05 Apr 2025 07:10:01 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pg1-x536.google.com (mail-pg1-x536.google.com [IPv6:2607:f8b0: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 4ZV66x34mxz400k for ; Sat, 05 Apr 2025 07:09:56 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pg1-x536.google.com with SMTP id 41be03b00d2f7-af589091049so1839372a12.1 for ; Sat, 05 Apr 2025 00:09:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1743836995; x=1744441795; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=wRwnyFYJBl6DmzLn6palRYhnzT37QDL84wTOTasaujQ=; b=d92jcR043gJQ9MoVZlrVVVa89TwdujbXEH/eEw2tZd4E1nLr+C1xcOqN3MV3JRP+FM OzA78BVYfA/Te+E8bBaF4egVppEzOKw8Zhx/vrHRPENlAPEP80IawArHkl5DhykOv1F3 EeRZvgCXfDgZuCtCCt1lNKPauNRUNCa0OByNwKRMUtb9/e+Br/EK4qYjPKXQvFcqyng8 I1/V3t0eO1G2ZU6Ut51z1sltq5jHwr/CNYBB10y91BrNP11qk7KKlpvDrM+BXsbMKhGi sK9qHAe7jqow3u/To/xgSBo6gpm3N3dBJguSnpuDn/bAYKkxX38tXWE1W5EZCrO1ae7X bMMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743836995; x=1744441795; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=wRwnyFYJBl6DmzLn6palRYhnzT37QDL84wTOTasaujQ=; b=JFsVXGrh2/6gwnTOSUJYYh4Ild6h/eBF+8SM5MldLanGQJFItPwy2ti0uiJ7bunKEH hAks+6XIWoT0ute2EB8tSMosPzi3OcokdGkPOQza2CeOAFTk0d6KlY6nPV/NoXMpA8o5 oA7Z27WeWs49ZY8IR25LiJBMkxVCgOnos5XvrOAhmIsKsvrGdGVh49UsK0a4uEW2ecat oKOJdiCLxc5kWR6O2XYTFvu4y5sq18hXdLQDu4qCqvFvfPIShfQsRrXb/1xgOR5oWiOs LxZ9sggNXOJOQ/MdAOvRBwxrFFewNqAP/VOuscbeloA9tLYHxN8sDnlYaLRmjepYI2Ns wFVA== X-Forwarded-Encrypted: i=1; AJvYcCWqqtKii28qtEEDzsm0vbeQXxB3SrbyBzLkmUEmCzxOp0rVl3dseYglND7DXiq4Mi7+qNAVcZwt4t/kmiMd0Kc=@freebsd.org X-Gm-Message-State: AOJu0YxxvanB/PKRZYa4K+Hhl4wrOgAfc+XlGCrzwUZk02gWtgQglqmf UxUry1BaodpdB0j3xqKuRISRmfE8PVjySG2qCrO99eW0/miXKX42seM+a8yEcgtMFzHso8UQsS5 fCjmkX8D0ZwWN2LuJbzcMrNLn8I9htinqH+N6Bg== X-Gm-Gg: ASbGnct6v6Q0LcnK95iuKgdbkekiLClYpsfhQkhB1DL0OSgokcjJVkdJZ+epGVFnfDw I3RLNlWM29IcuB/DGLCkhu+npjs1TLDipwiLF7w6vbCw+zYay3GOAbfGRzlHkySvVNDnHuTUTeQ lOlXlyc/eU7IbTyFk+s9rBiI/GBcs4X0heGJGM7UmwfGLEop0+rQMvPSenzohShl3e4mI= X-Google-Smtp-Source: AGHT+IHHGuu5MlnAbe9gcXjHEbbyBmZ6XoKiHzCrE+PMS8PYvypQTiZ7ZSj5to+LIQpgZ5SVKc1xu4mhL5KWh1p8RB4= X-Received: by 2002:a17:90b:1c06:b0:2ee:d371:3227 with SMTP id 98e67ed59e1d1-306a4899cddmr9744901a91.17.1743836994971; Sat, 05 Apr 2025 00:09: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: <39bd6092-4bd9-4086-b202-08b83b425fb5@comcast.net> <35d2361d-80e8-489a-bd9d-6c5ada5736b8@FreeBSD.org> <591a0d84-a74a-4d8e-bd40-04475eb5b457@comcast.net> <20250405125636.b078c4cdd3638a677af16494@dec.sakura.ne.jp> In-Reply-To: <20250405125636.b078c4cdd3638a677af16494@dec.sakura.ne.jp> From: Warner Losh Date: Sat, 5 Apr 2025 01:09:43 -0600 X-Gm-Features: ATxdqUGV3lBjBy5hs-zpubXoOpEgbGgvxw2fsvnAEOKzhQOoYp2_bpCctC1Zhzs Message-ID: Subject: Re: Samsung T7 external SSD support? To: Tomoaki AOKI Cc: Steve Kargl , Alexander Motin , FreeBSD Current Content-Type: multipart/alternative; boundary="000000000000a1db1a063202b005" X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4ZV66x34mxz400k X-Spamd-Bar: ---- --000000000000a1db1a063202b005 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Apr 4, 2025, 9:57=E2=80=AFPM Tomoaki AOKI wrote: > On Fri, 4 Apr 2025 19:44:49 -0700 > Steve Kargl wrote: > > > On 4/4/25 19:28, Alexander Motin wrote: > > > On 04.04.2025 21:45, Steve Kargl wrote: > > >> Anyone using a Samsung T7 external SSD with FreeBSD current? > > >> > > >> If I plug the drive into a USB 2.0 port, I see > > >> > > >> usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage > > >> device Samsung PSSD T7 Shield (0x04e8:0x61fb) > > >> ugen0.2: at usbus0 > > >> umass0 on uhub1 > > >> umass0: > on > > >> usbus0 > > >> umass0: SCSI over Bulk-Only; quirks =3D 0x0100 > > >> umass0:5:0: Attached to scbus5 > > >> da0 at umass-sim0 bus 0 scbus5 target 0 lun 0 > > >> da0: Fixed Direct Access SPC-4 SCSI devic= e > > >> da0: Serial Number S6NPNS0Y201077Y > > >> da0: 40.000MB/s transfers > > >> da0: 1907729MB (3907029168 512 byte sectors) > > >> da0: quirks=3D0x2 > > >> > > >> However, the SSD is supposedly a USB 3.2 gen 2 device with a ~1000 > MBps > > >> read/write speed. > > >> > > >> When plugged into a USB 3.x port, I typically see > > >> > > >> ugen0.2: at usbus0 > > >> > > >> and the device is not listed with usbconfig. Repeatedly, unplugging > the > > >> ssd and re-plugging it into the USB 3.x port, I eventually get the > > >> above dmesg output. Do I need a quirk for this SSD to get > > >> recognized? Also, > > >> shouldn't it connect with faster transfer rate than 'da0: 40.0MB/s'? > > > > > > 40MB/s exactly means the device connected to USB2 controller or at > least > > > at USB2 speed. Considering that other times it does not connect at > all, > > > I wonder if some signal quality issue or something else prevents it > from > > > going proper USB3. IIRC USB3 uses completely different wires in the > > > connector. Also USB2 and USB3 can be handled by different controller= s > > > with different drivers, so not detecting it still might be a software > > > issue, but I can't say much about that area. > > > > Thanks for confirming my suspension. > > > > I've tried two different cables. I have few more I can test. > > Unfortunately, I have to use a short USB 3.x extension cable > > as the port is on the motherboard under a table. > > > > -- > > steve > > Another unwanted possibility would be that controller mimic'ing SCSI > (As reported being "umass0: SCSI over Bulk-Only") is reporting as if > it's U2 or UW SCSI device. > No. Reported speed doesn't matter. It's reported by the SIM and is a guess. For USB attached it doesn't change anything. Warner > https://en.wikipedia.org/wiki/SCSI > > https://en.wikipedia.org/wiki/SCSI > > > -- > Tomoaki AOKI > > --000000000000a1db1a063202b005 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Apr 4, 2025, 9:57=E2=80= =AFPM Tomoaki AOKI <junchoo= n@dec.sakura.ne.jp> wrote:
O= n Fri, 4 Apr 2025 19:44:49 -0700
Steve Kargl <kargls@comcast.net> wrote:

> On 4/4/25 19:28, Alexander Motin wrote:
> > On 04.04.2025 21:45, Steve Kargl wrote:
> >> Anyone using a Samsung T7 external SSD with FreeBSD current?<= br> > >>
> >> If I plug the drive into a USB 2.0 port, I see
> >>
> >> usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass stor= age
> >> device Samsung PSSD T7 Shield (0x04e8:0x61fb)
> >> ugen0.2: <Samsung PSSD T7 Shield> at usbus0
> >> umass0 on uhub1
> >> umass0: <Samsung PSSD T7 Shield, class 0/0, rev 2.10/1.00,= addr 47> on
> >> usbus0
> >> umass0:=C2=A0 SCSI over Bulk-Only; quirks =3D 0x0100
> >> umass0:5:0: Attached to scbus5
> >> da0 at umass-sim0 bus 0 scbus5 target 0 lun 0
> >> da0: <Samsung PSSD T7 Shield 0> Fixed Direct Access SPC= -4 SCSI device
> >> da0: Serial Number S6NPNS0Y201077Y
> >> da0: 40.000MB/s transfers
> >> da0: 1907729MB (3907029168 512 byte sectors)
> >> da0: quirks=3D0x2<NO_6_BYTE>
> >>
> >> However, the SSD is supposedly a USB 3.2 gen 2 device with a = ~1000 MBps
> >> read/write speed.
> >>
> >> When plugged into a USB 3.x port, I typically see
> >>
> >> ugen0.2: <vendor 0x0507 product 0x0204> at usbus0
> >>
> >> and the device is not listed with usbconfig.=C2=A0 Repeatedly= , unplugging the
> >> ssd and re-plugging it into the USB 3.x port, I eventually ge= t the
> >> above dmesg output.=C2=A0 Do I need a quirk for this SSD to g= et
> >> recognized?=C2=A0 Also,
> >> shouldn't it connect with faster transfer rate than '= da0: 40.0MB/s'?
> >
> > 40MB/s exactly means the device connected to USB2 controller or a= t least
> > at USB2 speed.=C2=A0 Considering that other times it does not con= nect at all,
> > I wonder if some signal quality issue or something else prevents = it from
> > going proper USB3.=C2=A0 IIRC USB3 uses completely different wire= s in the
> > connector.=C2=A0 Also USB2 and USB3 can be handled by different c= ontrollers
> > with different drivers, so not detecting it still might be a soft= ware
> > issue, but I can't say much about that area.
>
> Thanks for confirming my suspension.
>
> I've tried two different cables.=C2=A0 I have few more I can test.=
> Unfortunately, I have to use a short USB 3.x extension cable
> as the port is on the motherboard under a table.
>
> --
> steve

Another unwanted possibility would be that controller mimic'ing SCSI (As reported being "umass0:=C2=A0 SCSI over Bulk-Only") is report= ing as if
it's U2 or UW SCSI device.


No. Reported spee= d doesn't matter. It's reported by the SIM and is a guess. For USB = attached it doesn't change anything.

<= div dir=3D"auto">Warner

--000000000000a1db1a063202b005-- From nobody Sat Apr 5 07:11: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 4ZV68Z3hgmz5rQ7x for ; Sat, 05 Apr 2025 07:11:26 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) (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 4ZV68Y6r8kz419R for ; Sat, 05 Apr 2025 07:11:25 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pj1-x1032.google.com with SMTP id 98e67ed59e1d1-3054ef26da3so2191790a91.3 for ; Sat, 05 Apr 2025 00:11:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1743837084; x=1744441884; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=VKv4ywtGPyZpxLb5nXHgfDfbkg8sGkYWCx+YHmwH2Us=; b=UKpUpLUn/hEudOtfjHYjSQz16tJAyOT+/hGcd+iDQjR+YfE8W5/zx4LC+8KpNe7LL+ 8vAtw8Lmf0mr0+EdponPB+dvyeWR4Hzt4MsKt0XW1aPCfRWrbvrSuNL/AuUzXF+0+wPB Izt4DG9I9kukAQ3M3WSUgRgFVR3WZVq/fKk3ITirSD5mvxs/kwY+OEtMKssXwoM5YN0j uoCOC541CQXR7wAh3TgcdVAFp7UdJKxn/YtOJpUxGFY7uYeTIGY8zw8hx08LBWda6rx2 vQIlXBUWoRjyg3ep3IrKXaJgEhU5m7FCzvbLKHO8pP26wubKY50Oq8jG41MTPm7dLgQp t7cw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743837084; x=1744441884; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=VKv4ywtGPyZpxLb5nXHgfDfbkg8sGkYWCx+YHmwH2Us=; b=BwTNlHhDWHsYug4EKk58SUZx5+/UR5gP4RXSg/ud6v2SOaVPwhR1kJtS7QWT//5NHm LJH7GYn8ryudWStlEHD2IhQKc2wquoDshewLVTChJvkwZ0peAydF2WKg/851Kk2nt/1B YVJ2t6Y9+nOLa+FEHVOi8kuPyZp/ZnMCUu6wGi/Uo7dhSJw8HO2VJHt4+0EuL2QppinM 1NcQrS7DamE9FVz9L98MotjqXf4/IBAKgk6hPZa1TUJYoTkEvKspujMWek7MijNouWYw TFPHANDyBN+u+akaqfmogXt9kM0h6LnmBh6kGwfUVyyYloLvYI6VASpDL1MUGiTQRJDu Y4Yg== X-Gm-Message-State: AOJu0Yx2rnhYeXkZskOb3jK2FjYbIfSFdS/KS6JDiRmJwRgMqc/66t6F iXXB5pvgbMu8huQ2KvkCHQDWBmpn8s290Y0YvdsmRZ1siAGBMXdKyE7oLaGANdOddTQAR1cqa7A finWmSUAZR411VlisVTq+eQrBkeiMYflesntmNq/DJB2j3jTM X-Gm-Gg: ASbGncsOWJeVzzNYFxlX9GHGT5SqAB+mEkvbbkekKyK1PS0wxjdredGacQD2Ji2q0T7 ZliRimd0sNhSqrCgT1b0ng73JEozAWCHoya/9ckLxr15QjQReK53zCYgxpn2s/fe1S81PcVAXhL RdDnyL75QHYNaSuirtKlY6HDvzXxg/5C5kMGGdN5Nt1bKvXhk50vDShyux X-Google-Smtp-Source: AGHT+IEP7FQjLxBQSmIXNbGnhD8c5HG8IRAlyUhQUg6R91oi6FByu1ln4Ck22Q8bKyrEqLZduIvL3b9b9k/jble7phw= X-Received: by 2002:a17:90b:1cc4:b0:2fe:b470:dde4 with SMTP id 98e67ed59e1d1-306a4860a10mr9771011a91.12.1743837084580; Sat, 05 Apr 2025 00:11:24 -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: <39bd6092-4bd9-4086-b202-08b83b425fb5@comcast.net> <35d2361d-80e8-489a-bd9d-6c5ada5736b8@FreeBSD.org> <591a0d84-a74a-4d8e-bd40-04475eb5b457@comcast.net> In-Reply-To: From: Warner Losh Date: Sat, 5 Apr 2025 01:11:13 -0600 X-Gm-Features: ATxdqUFvWQDaiE7FA7XPe-9QAhAdaNtbKGvcG4d6C3cUU61x0R7RosxTW-xnpD8 Message-ID: Subject: Re: Samsung T7 external SSD support? To: Steve Kargl Cc: FreeBSD Current Content-Type: multipart/alternative; boundary="000000000000f91653063202b5a9" X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4ZV68Y6r8kz419R X-Spamd-Bar: ---- --000000000000f91653063202b5a9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Apr 4, 2025, 11:47=E2=80=AFPM Steve Kargl wrot= e: > On 4/4/25 19:44, Steve Kargl wrote: > > On 4/4/25 19:28, Alexander Motin wrote: > >> On 04.04.2025 21:45, Steve Kargl wrote: > >>> Anyone using a Samsung T7 external SSD with FreeBSD current? > >>> > >>> If I plug the drive into a USB 2.0 port, I see > >>> > >>> usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage > >>> device Samsung PSSD T7 Shield (0x04e8:0x61fb) > >>> ugen0.2: at usbus0 > >>> umass0 on uhub1 > >>> umass0: > >>> on usbus0 > >>> umass0: SCSI over Bulk-Only; quirks =3D 0x0100 > >>> umass0:5:0: Attached to scbus5 > >>> da0 at umass-sim0 bus 0 scbus5 target 0 lun 0 > >>> da0: Fixed Direct Access SPC-4 SCSI device > >>> da0: Serial Number S6NPNS0Y201077Y > >>> da0: 40.000MB/s transfers > >>> da0: 1907729MB (3907029168 512 byte sectors) > >>> da0: quirks=3D0x2 > >>> > >>> However, the SSD is supposedly a USB 3.2 gen 2 device with a ~1000 MB= ps > >>> read/write speed. > >>> > >>> When plugged into a USB 3.x port, I typically see > >>> > >>> ugen0.2: at usbus0 > >>> > >>> and the device is not listed with usbconfig. Repeatedly, unplugging > the > >>> ssd and re-plugging it into the USB 3.x port, I eventually get the > >>> above dmesg output. Do I need a quirk for this SSD to get > >>> recognized? Also, > >>> shouldn't it connect with faster transfer rate than 'da0: 40.0MB/s'? > >> > >> 40MB/s exactly means the device connected to USB2 controller or at > >> least at USB2 speed. Considering that other times it does not connect > >> at all, I wonder if some signal quality issue or something else > >> prevents it from going proper USB3. IIRC USB3 uses completely > >> different wires in the connector. Also USB2 and USB3 can be handled > >> by different controllers with different drivers, so not detecting it > >> still might be a software issue, but I can't say much about that area. > > > > Thanks for confirming my suspension. > > > > I've tried two different cables. I have few more I can test. > > Unfortunately, I have to use a short USB 3.x extension cable > > as the port is on the motherboard under a table. > > > > Climbing under the table and plugging directly into the motherboard > gives > usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage device > Samsung PSSD T7 Shield (0x04e8:0x61fb) > ugen2.2: at usbus2 > umass0 on uhub0 > umass0: on > usbus2 > umass0: SCSI over Bulk-Only; quirks =3D 0x0100 > umass0:5:0: Attached to scbus5 > da0 at umass-sim0 bus 0 scbus5 target 0 lun 0 > da0: Fixed Direct Access SPC-4 SCSI device > da0: Serial Number S6NPNS0Y201077Y > da0: 400.000MB/s transfers > da0: 1907729MB (3907029168 512 byte sectors) > da0: quirks=3D0x2 > > which is what I expected. So, the extension cable seems to be > an issue. > What is the dd performance? Warner > > -- > steve > > --000000000000f91653063202b5a9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Apr 4, 2025, 11:47=E2=80= =AFPM Steve Kargl <kargls@comcast.= net> wrote:
On 4/4/25 19:44,= Steve Kargl wrote:
> On 4/4/25 19:28, Alexander Motin wrote:
>> On 04.04.2025 21:45, Steve Kargl wrote:
>>> Anyone using a Samsung T7 external SSD with FreeBSD current? >>>
>>> If I plug the drive into a USB 2.0 port, I see
>>>
>>> usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass stora= ge
>>> device Samsung PSSD T7 Shield (0x04e8:0x61fb)
>>> ugen0.2: <Samsung PSSD T7 Shield> at usbus0
>>> umass0 on uhub1
>>> umass0: <Samsung PSSD T7 Shield, class 0/0, rev 2.10/1.00, = addr 47>
>>> on usbus0
>>> umass0:=C2=A0 SCSI over Bulk-Only; quirks =3D 0x0100
>>> umass0:5:0: Attached to scbus5
>>> da0 at umass-sim0 bus 0 scbus5 target 0 lun 0
>>> da0: <Samsung PSSD T7 Shield 0> Fixed Direct Access SPC-= 4 SCSI device
>>> da0: Serial Number S6NPNS0Y201077Y
>>> da0: 40.000MB/s transfers
>>> da0: 1907729MB (3907029168 512 byte sectors)
>>> da0: quirks=3D0x2<NO_6_BYTE>
>>>
>>> However, the SSD is supposedly a USB 3.2 gen 2 device with a ~= 1000 MBps
>>> read/write speed.
>>>
>>> When plugged into a USB 3.x port, I typically see
>>>
>>> ugen0.2: <vendor 0x0507 product 0x0204> at usbus0
>>>
>>> and the device is not listed with usbconfig.=C2=A0 Repeatedly,= unplugging the
>>> ssd and re-plugging it into the USB 3.x port, I eventually get= the
>>> above dmesg output.=C2=A0 Do I need a quirk for this SSD to ge= t
>>> recognized?=C2=A0 Also,
>>> shouldn't it connect with faster transfer rate than 'd= a0: 40.0MB/s'?
>>
>> 40MB/s exactly means the device connected to USB2 controller or at=
>> least at USB2 speed.=C2=A0 Considering that other times it does no= t connect
>> at all, I wonder if some signal quality issue or something else >> prevents it from going proper USB3.=C2=A0 IIRC USB3 uses completel= y
>> different wires in the connector.=C2=A0 Also USB2 and USB3 can be = handled
>> by different controllers with different drivers, so not detecting = it
>> still might be a software issue, but I can't say much about th= at area.
>
> Thanks for confirming my suspension.
>
> I've tried two different cables.=C2=A0 I have few more I can test.=
> Unfortunately, I have to use a short USB 3.x extension cable
> as the port is on the motherboard under a table.
>

Climbing under the table and plugging directly into the motherboard
gives
usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage device Samsung PSSD T7 Shield (0x04e8:0x61fb)
ugen2.2: <Samsung PSSD T7 Shield> at usbus2
umass0 on uhub0
umass0: <Samsung PSSD T7 Shield, class 0/0, rev 3.20/1.00, addr 1> on= usbus2
umass0:=C2=A0 SCSI over Bulk-Only; quirks =3D 0x0100
umass0:5:0: Attached to scbus5
da0 at umass-sim0 bus 0 scbus5 target 0 lun 0
da0: <Samsung PSSD T7 Shield 0> Fixed Direct Access SPC-4 SCSI device=
da0: Serial Number S6NPNS0Y201077Y
da0: 400.000MB/s transfers
da0: 1907729MB (3907029168 512 byte sectors)
da0: quirks=3D0x2<NO_6_BYTE>

which is what I expected.=C2=A0 So, the extension cable seems to be
an issue.

What is the dd performance?

Warner=C2=A0

--
steve

--000000000000f91653063202b5a9-- From nobody Sat Apr 5 08:40: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 4ZV87T1ng1z5rXQw for ; Sat, 05 Apr 2025 08:40:37 +0000 (UTC) (envelope-from soren.schmidt@gmail.com) Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZV87S6QJfz3Fsl; Sat, 05 Apr 2025 08:40:36 +0000 (UTC) (envelope-from soren.schmidt@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ej1-x629.google.com with SMTP id a640c23a62f3a-abf3d64849dso426804466b.3; Sat, 05 Apr 2025 01:40:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1743842435; x=1744447235; darn=freebsd.org; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=RlnQuyjnsqqSTMs8gWYhm9CjLIvvnVAHq08+3msoBh4=; b=DGqvvDIuvKFzfZ7hv1ptmFtblEA3i+GjL1fMhoz6zvPYp9+0SUC53T5VBj7PwL8VxK EiMrW8HZuKJN3hOo4TMQy8Uh4lGfKXrFKxVj1bwJz/5joxM6Bq6jwofhZNj9vS3PVFfr R0Kcl14wbZpBafTGB2Xs5Mv0ShiV9mUwk9szZEEYgj9RHcCPeKPHuvlBsx6PW1u8Jx7F 0TghpSstpCSLLDaE0ok4lVzxDvwZP+dtqeauSlDROCEo32ZJisTre9+WOj3L4cowPrJP P2xR228GpijkWUzvu3pY4b20ZTv4tymivU+zGfQldzel1qebShRn4qow2AMnLmZt+b7z CtVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743842435; x=1744447235; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=RlnQuyjnsqqSTMs8gWYhm9CjLIvvnVAHq08+3msoBh4=; b=GoxzObznxxFPFbpbHbJMzn4daU9xCvmw5pJp6kypqQfEH7vH5qPmjYLvAvk3UvADKD PTzwl1BbxAoQ428RWf+ZPDtS0nOeFQL5TCpivFkm/A0gWWC9AssfKWohnDbTlufFdVNv KKS7eoemEPOpAc+jDJoF6uXdVNPQI7iVnoajBQKTnv0rIdgKQaI7HSWeH0zN0POtrAv/ vvq+UW2CgBf/WLBeNXRw0FCNUolXagtSNvi+KvmF9cRiE1nb6eRqYb5JIEpycZTK0Ims RTKmn8BIZJOgSc0EKZxjn5Jv0LIebmndknIu69unAbDc37WNEKncazlFCVmWANGCUkN1 g0aQ== X-Forwarded-Encrypted: i=1; AJvYcCUI7pj4poLci5aeKZvUob/YoqZBDHCptooCRX+16O2l0SrpM9b3XbPEHJKfOQ7YRkYaKFtIYvHlToYvs+6L1Ts=@freebsd.org, AJvYcCX58IQzmJy6bz2N1d6gzwVy1jnKv3VkP2DT7R2tyZNpSunC7Oj6ovWEp6bpvyWHXGcxlR6Q@freebsd.org X-Gm-Message-State: AOJu0YxwBQch6/nhgIoeZzei0JDBhHxti1I1c105ph/81U7kxfVVTwhc lZl4GNErYvJjRQVWGZQfaqEl8Bi7e8r20wPn78lCjmPlT+gg9m8J X-Gm-Gg: ASbGncvueX4WXhS1btD5hyg69TLCM47iQBNXhPH6BLUNgglWyU4OBeSa+I5vn5yazf8 bfOzdtjyZJkyk/9k5/SOR2SP7HAlCkEHISt6be8DAyuaIC/HUEnF/pOwTJgoFAZkxxDVM7i6JzR CZwiv8Lmu1VqaaEjhoNOvUjBIdIOMy+vMF3iTfaNAoI0xISoJxMvBg0vzKBjWUr6yvO+Tjjiz8h DRJH7XCkWJZhUSPWKpRKSUrJ67SNj5ENncUKDbJJ+xlKsbMgwlmtRIhLj++7CLoK72A16hLtlkj yxjU9zKs/HaQ8UPfi83w1K8aNXNckz7FUIF6sd9ZifisKp6rAEz9UjeJE+D7yqrUIb/E X-Google-Smtp-Source: AGHT+IFsvM+AD2TqgFAYOuGz7lLbP3rA7DR92rjQRkBFrT8E+Ans9zHdereewZiw0sGv7QxgZ1vsew== X-Received: by 2002:a17:907:9443:b0:ac6:ba91:ca4d with SMTP id a640c23a62f3a-ac7d17da774mr453317866b.31.1743842435003; Sat, 05 Apr 2025 01:40:35 -0700 (PDT) Received: from smtpclient.apple (s61.dk. [85.27.186.9]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-ac7c0185726sm381151166b.137.2025.04.05.01.40.34 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 05 Apr 2025 01:40:34 -0700 (PDT) From: =?utf-8?Q?S=C3=B8ren_Schmidt?= Message-Id: <556C4487-2E81-46E8-A9D6-3F8AE7896952@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_C6EF5D46-4EE8-489A-AEA5-AE124E2E2A8D" 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: Re: Samsung T7 external SSD support? Date: Sat, 5 Apr 2025 10:40:23 +0200 In-Reply-To: <20250405125636.b078c4cdd3638a677af16494@dec.sakura.ne.jp> Cc: Steve Kargl , Alexander Motin , freebsd-current@freebsd.org To: Tomoaki AOKI References: <39bd6092-4bd9-4086-b202-08b83b425fb5@comcast.net> <35d2361d-80e8-489a-bd9d-6c5ada5736b8@FreeBSD.org> <591a0d84-a74a-4d8e-bd40-04475eb5b457@comcast.net> <20250405125636.b078c4cdd3638a677af16494@dec.sakura.ne.jp> X-Mailer: Apple Mail (2.3826.400.131.1.6) 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: 4ZV87S6QJfz3Fsl X-Spamd-Bar: ---- --Apple-Mail=_C6EF5D46-4EE8-489A-AEA5-AE124E2E2A8D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 S=C3=B8ren Schmidt soren.schmidt@gmail.com > On 5 Apr 2025, at 05.56, Tomoaki AOKI = wrote: >=20 > On Fri, 4 Apr 2025 19:44:49 -0700 > Steve Kargl wrote: >=20 >> On 4/4/25 19:28, Alexander Motin wrote: >>> On 04.04.2025 21:45, Steve Kargl wrote: >>>> Anyone using a Samsung T7 external SSD with FreeBSD current? >>>>=20 >>>> If I plug the drive into a USB 2.0 port, I see >>>>=20 >>>> usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage=20 >>>> device Samsung PSSD T7 Shield (0x04e8:0x61fb) >>>> ugen0.2: at usbus0 >>>> umass0 on uhub1 >>>> umass0: = on=20 >>>> usbus0 >>>> umass0: SCSI over Bulk-Only; quirks =3D 0x0100 >>>> umass0:5:0: Attached to scbus5 >>>> da0 at umass-sim0 bus 0 scbus5 target 0 lun 0 >>>> da0: Fixed Direct Access SPC-4 SCSI = device >>>> da0: Serial Number S6NPNS0Y201077Y >>>> da0: 40.000MB/s transfers >>>> da0: 1907729MB (3907029168 512 byte sectors) >>>> da0: quirks=3D0x2 >>>>=20 >>>> However, the SSD is supposedly a USB 3.2 gen 2 device with a ~1000 = MBps >>>> read/write speed. >>>>=20 >>>> When plugged into a USB 3.x port, I typically see >>>>=20 >>>> ugen0.2: at usbus0 >>>>=20 >>>> and the device is not listed with usbconfig. Repeatedly, = unplugging the >>>> ssd and re-plugging it into the USB 3.x port, I eventually get the=20= >>>> above dmesg output. Do I need a quirk for this SSD to get=20 >>>> recognized? Also, >>>> shouldn't it connect with faster transfer rate than 'da0: = 40.0MB/s'? >>>=20 >>> 40MB/s exactly means the device connected to USB2 controller or at = least=20 >>> at USB2 speed. Considering that other times it does not connect at = all,=20 >>> I wonder if some signal quality issue or something else prevents it = from=20 >>> going proper USB3. IIRC USB3 uses completely different wires in the=20= >>> connector. Also USB2 and USB3 can be handled by different = controllers=20 >>> with different drivers, so not detecting it still might be a = software=20 >>> issue, but I can't say much about that area. >>=20 >> Thanks for confirming my suspension. >>=20 >> I've tried two different cables. I have few more I can test. >> Unfortunately, I have to use a short USB 3.x extension cable >> as the port is on the motherboard under a table. Well, if you are using USB C you could try to turn the connector 180 = degrees around (it fits both ways apposed to the old connectors), = depending on driver quality and fase of the moon the USB3 side might not = be seen both ways =E2=80=A6 S=C3=B8ren Schmidt sos@deepcore.dk / sos@freebsd.org "So much code to hack, so little time" --Apple-Mail=_C6EF5D46-4EE8-489A-AEA5-AE124E2E2A8D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
S=C3=B8ren = Schmidt
soren.schmidt@gmail.com



On 5 Apr 2025, at 05.56, Tomoaki = AOKI <junchoon@dec.sakura.ne.jp> wrote:

On Fri, 4 Apr 2025 = 19:44:49 -0700
Steve Kargl <kargls@comcast.net> = wrote:

On 4/4/25 19:28, Alexander Motin = wrote:
On 04.04.2025 21:45, Steve Kargl = wrote:
Anyone using a Samsung T7 external = SSD with FreeBSD current?

If I plug the drive into a USB 2.0 = port, I see

usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB = mass storage
device Samsung PSSD T7 Shield = (0x04e8:0x61fb)
ugen0.2: <Samsung PSSD T7 Shield> at = usbus0
umass0 on uhub1
umass0: <Samsung PSSD T7 Shield, class = 0/0, rev 2.10/1.00, addr 47> on
usbus0
umass0:  SCSI over = Bulk-Only; quirks =3D 0x0100
umass0:5:0: Attached to scbus5
da0 at = umass-sim0 bus 0 scbus5 target 0 lun 0
da0: <Samsung PSSD T7 = Shield 0> Fixed Direct Access SPC-4 SCSI device
da0: Serial Number = S6NPNS0Y201077Y
da0: 40.000MB/s transfers
da0: 1907729MB = (3907029168 512 byte sectors)
da0: = quirks=3D0x2<NO_6_BYTE>

However, the SSD is supposedly a = USB 3.2 gen 2 device with a ~1000 MBps
read/write speed.

When = plugged into a USB 3.x port, I typically see

ugen0.2: <vendor = 0x0507 product 0x0204> at usbus0

and the device is not listed = with usbconfig.  Repeatedly, unplugging the
ssd and re-plugging = it into the USB 3.x port, I eventually get the
above dmesg = output.  Do I need a quirk for this SSD to get =
recognized?  Also,
shouldn't it connect with faster transfer = rate than 'da0: 40.0MB/s'?

40MB/s exactly means the = device connected to USB2 controller or at least
at USB2 speed.  = Considering that other times it does not connect at all,
I wonder if = some signal quality issue or something else prevents it from
going = proper USB3.  IIRC USB3 uses completely different wires in the =
connector.  Also USB2 and USB3 can be handled by different = controllers
with different drivers, so not detecting it still might = be a software
issue, but I can't say much about that = area.

Thanks for confirming my = suspension.

I've tried two different cables.  I have few = more I can test.
Unfortunately, I have to use a short USB 3.x = extension cable
as the port is on the motherboard under a = table.

Well, if you = are using USB C you could try to turn the connector 180 degrees around = (it fits both ways apposed to the old connectors), depending on driver = quality and fase of the moon the USB3 side might not be seen both ways = =E2=80=A6

S=C3=B8ren Schmidt
sos@deepcore.dk / sos@freebsd.org
"So much code to hack, so little = time"


= --Apple-Mail=_C6EF5D46-4EE8-489A-AEA5-AE124E2E2A8D-- From nobody Sat Apr 5 11:16:42 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 4ZVCvp2kdrz5s2jJ for ; Sat, 05 Apr 2025 11:30:46 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from gid2.gid.co.uk (ns0.gid.co.uk [IPv6:2001:470:94de::240]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gid2.gid.co.uk", Issuer "gid2.gid.co.uk" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZVCvm6hlvz3h6p; Sat, 05 Apr 2025 11:30:44 +0000 (UTC) (envelope-from rb@gid.co.uk) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=gid.co.uk; spf=pass (mx1.freebsd.org: domain of rb@gid.co.uk designates 2001:470:94de::240 as permitted sender) smtp.mailfrom=rb@gid.co.uk Received: from mx0.gid.co.uk (mx0.gid.co.uk [194.32.164.250]) by gid2.gid.co.uk (8.15.2/8.15.2) with ESMTP id 535BGwZN069968; Sat, 5 Apr 2025 12:16:58 +0100 (BST) (envelope-from rb@gid.co.uk) Received: from smtpclient.apple (moriarty.gid.co.uk [194.32.164.17]) by mx0.gid.co.uk (8.14.2/8.14.2) with ESMTP id 535BGqSv084278; Sat, 5 Apr 2025 12:16:52 +0100 (BST) (envelope-from rb@gid.co.uk) From: Bob Bishop Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_CA2F09CE-9DBB-4D6D-A163-197601307056" 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 \(3776.700.51.11.1\)) Subject: Re: Samsung T7 external SSD support? Date: Sat, 5 Apr 2025 12:16:42 +0100 In-Reply-To: <556C4487-2E81-46E8-A9D6-3F8AE7896952@gmail.com> Cc: Tomoaki AOKI , Alexander Motin , =?utf-8?Q?S=C3=B8ren_Schmidt?= , "freebsd-current@freebsd.org" To: Steve Kargl References: <39bd6092-4bd9-4086-b202-08b83b425fb5@comcast.net> <35d2361d-80e8-489a-bd9d-6c5ada5736b8@FreeBSD.org> <591a0d84-a74a-4d8e-bd40-04475eb5b457@comcast.net> <20250405125636.b078c4cdd3638a677af16494@dec.sakura.ne.jp> <556C4487-2E81-46E8-A9D6-3F8AE7896952@gmail.com> X-Mailer: Apple Mail (2.3776.700.51.11.1) X-Spamd-Result: default: False [2.44 / 15.00]; SUSPICIOUS_RECIPS(1.50)[]; SUSPICIOUS_URL_IN_SUSPICIOUS_MESSAGE(1.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-0.85)[-0.846]; NEURAL_HAM_SHORT(-0.69)[-0.689]; NEURAL_HAM_MEDIUM(-0.63)[-0.628]; URIBL_RED(0.50)[dec.sakura.ne.jp:email]; MV_CASE(0.50)[]; HAS_ANON_DOMAIN(0.10)[]; BAD_REP_POLICIES(0.10)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; FREEMAIL_CC(0.00)[dec.sakura.ne.jp,FreeBSD.org,gmail.com]; FROM_HAS_DN(0.00)[]; FREEMAIL_TO(0.00)[comcast.net]; GREYLIST(0.00)[pass,body]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; ARC_NA(0.00)[]; DMARC_POLICY_ALLOW(0.00)[gid.co.uk,none]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; R_SPF_ALLOW(0.00)[+mx:c]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; TO_DN_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@FreeBSD.org]; MID_RHS_MATCH_FROM(0.00)[]; R_DKIM_NA(0.00)[]; TAGGED_RCPT(0.00)[]; RCPT_COUNT_FIVE(0.00)[5] X-Rspamd-Queue-Id: 4ZVCvm6hlvz3h6p X-Spamd-Bar: ++ --Apple-Mail=_CA2F09CE-9DBB-4D6D-A163-197601307056 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, > On 5 Apr 2025, at 09:40, S=C3=B8ren Schmidt = wrote: >=20 >=20 > S=C3=B8ren Schmidt > soren.schmidt@gmail.com >=20 >=20 >=20 >> On 5 Apr 2025, at 05.56, Tomoaki AOKI = wrote: >>=20 >> On Fri, 4 Apr 2025 19:44:49 -0700 >> Steve Kargl wrote: >>=20 >>> On 4/4/25 19:28, Alexander Motin wrote: >>>> On 04.04.2025 21:45, Steve Kargl wrote: >>>>> Anyone using a Samsung T7 external SSD with FreeBSD current? >>>>>=20 >>>>> If I plug the drive into a USB 2.0 port, I see >>>>>=20 >>>>> usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage=20= >>>>> device Samsung PSSD T7 Shield (0x04e8:0x61fb) >>>>> ugen0.2: at usbus0 >>>>> umass0 on uhub1 >>>>> umass0: on=20 >>>>> usbus0 >>>>> umass0: SCSI over Bulk-Only; quirks =3D 0x0100 >>>>> umass0:5:0: Attached to scbus5 >>>>> da0 at umass-sim0 bus 0 scbus5 target 0 lun 0 >>>>> da0: Fixed Direct Access SPC-4 SCSI = device >>>>> da0: Serial Number S6NPNS0Y201077Y >>>>> da0: 40.000MB/s transfers >>>>> da0: 1907729MB (3907029168 512 byte sectors) >>>>> da0: quirks=3D0x2 >>>>>=20 >>>>> However, the SSD is supposedly a USB 3.2 gen 2 device with a ~1000 = MBps >>>>> read/write speed. >>>>>=20 >>>>> When plugged into a USB 3.x port, I typically see >>>>>=20 >>>>> ugen0.2: at usbus0 >>>>>=20 >>>>> and the device is not listed with usbconfig. Repeatedly, = unplugging the >>>>> ssd and re-plugging it into the USB 3.x port, I eventually get the=20= >>>>> above dmesg output. Do I need a quirk for this SSD to get=20 >>>>> recognized? Also, >>>>> shouldn't it connect with faster transfer rate than 'da0: = 40.0MB/s'? >>>>=20 >>>> 40MB/s exactly means the device connected to USB2 controller or at = least=20 >>>> at USB2 speed. Considering that other times it does not connect at = all,=20 >>>> I wonder if some signal quality issue or something else prevents it = from=20 >>>> going proper USB3. IIRC USB3 uses completely different wires in = the=20 >>>> connector. Also USB2 and USB3 can be handled by different = controllers=20 >>>> with different drivers, so not detecting it still might be a = software=20 >>>> issue, but I can't say much about that area. >>>=20 >>> Thanks for confirming my suspension. >>>=20 >>> I've tried two different cables. I have few more I can test. >>> Unfortunately, I have to use a short USB 3.x extension cable >>> as the port is on the motherboard under a table. >=20 > Well, if you are using USB C you could try to turn the connector 180 = degrees around (it fits both ways apposed to the old connectors), = depending on driver quality and fase of the moon the USB3 side might not = be seen both ways =E2=80=A6 There are 8 distinct ways to plug in a USB C - USB C cable, and it=E2=80=99= s possible that they don=E2=80=99t all behave the same. I had such a = cable from Apple that failed in some orientations; once they had = recovered from their astonishment they replaced it. > S=C3=B8ren Schmidt > sos@deepcore.dk / sos@freebsd.org > "So much code to hack, so little time" >=20 >=20 -- Bob Bishop rb@gid.co.uk --Apple-Mail=_CA2F09CE-9DBB-4D6D-A163-197601307056 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

On 5 Apr 2025, at 09:40, S=C3=B8ren Schmidt = <soren.schmidt@gmail.com> wrote:


S=C3=B8ren = Schmidt
soren.schmidt@gmail.com



On 5 Apr 2025, at 05.56, Tomoaki = AOKI <junchoon@dec.sakura.ne.jp> wrote:

On Fri, 4 Apr 2025 = 19:44:49 -0700
Steve Kargl <kargls@comcast.net> = wrote:

On 4/4/25 19:28, Alexander Motin = wrote:
On 04.04.2025 21:45, Steve Kargl = wrote:
Anyone using a Samsung T7 external = SSD with FreeBSD current?

If I plug the drive into a USB 2.0 = port, I see

usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB = mass storage
device Samsung PSSD T7 Shield = (0x04e8:0x61fb)
ugen0.2: <Samsung PSSD T7 Shield> at = usbus0
umass0 on uhub1
umass0: <Samsung PSSD T7 Shield, class = 0/0, rev 2.10/1.00, addr 47> on
usbus0
umass0:  SCSI over = Bulk-Only; quirks =3D 0x0100
umass0:5:0: Attached to scbus5
da0 at = umass-sim0 bus 0 scbus5 target 0 lun 0
da0: <Samsung PSSD T7 = Shield 0> Fixed Direct Access SPC-4 SCSI device
da0: Serial Number = S6NPNS0Y201077Y
da0: 40.000MB/s transfers
da0: 1907729MB = (3907029168 512 byte sectors)
da0: = quirks=3D0x2<NO_6_BYTE>

However, the SSD is supposedly a = USB 3.2 gen 2 device with a ~1000 MBps
read/write speed.

When = plugged into a USB 3.x port, I typically see

ugen0.2: <vendor = 0x0507 product 0x0204> at usbus0

and the device is not listed = with usbconfig.  Repeatedly, unplugging the
ssd and re-plugging = it into the USB 3.x port, I eventually get the
above dmesg = output.  Do I need a quirk for this SSD to get =
recognized?  Also,
shouldn't it connect with faster transfer = rate than 'da0: 40.0MB/s'?

40MB/s exactly means the = device connected to USB2 controller or at least
at USB2 speed.  = Considering that other times it does not connect at all,
I wonder if = some signal quality issue or something else prevents it from
going = proper USB3.  IIRC USB3 uses completely different wires in the =
connector.  Also USB2 and USB3 can be handled by different = controllers
with different drivers, so not detecting it still might = be a software
issue, but I can't say much about that = area.

Thanks for confirming my = suspension.

I've tried two different cables.  I have few = more I can test.
Unfortunately, I have to use a short USB 3.x = extension cable
as the port is on the motherboard under a = table.

Well, if you = are using USB C you could try to turn the connector 180 degrees around = (it fits both ways apposed to the old connectors), depending on driver = quality and fase of the moon the USB3 side might not be seen both ways = =E2=80=A6

There are 8 = distinct ways to plug in a USB C - USB C cable, and it=E2=80=99s = possible that they don=E2=80=99t all behave the same. I had such a cable = from Apple that failed in some orientations; once they had recovered = from their astonishment they replaced it.

S=C3=B8ren Schmidt
sos@deepcore.dk / sos@freebsd.org
"So much code = to hack, so little time"
= --Apple-Mail=_CA2F09CE-9DBB-4D6D-A163-197601307056-- From nobody Sat Apr 5 15:50: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 4ZVKgr19J0z5sNJ2 for ; Sat, 05 Apr 2025 15:50:48 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (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 4ZVKgq64TTz4KW1 for ; Sat, 05 Apr 2025 15:50:47 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x534.google.com with SMTP id 4fb4d7f45d1cf-5efe8d9eb1eso174446a12.0 for ; Sat, 05 Apr 2025 08:50:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1743868245; x=1744473045; 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=iHW+RJQCwOlwS8oi37rmV/vGmWyAPsKoXtE6S+wJuBE=; b=KqCIwp1SlDaPR0RWZvnxxScfkq+3rUBvakXC8WB+7a1gMUIH/cWbMBvJxtmFGtLJye koTXTNWW034NRcr2IgJsDlWx6qvbw70B9cyZs3KHXady5qlJVsqJAZUWfoXHdbuc0JC2 257GzpUItgR0G8Tqb+W8SXn29fhErie3AGKkc2a04JqpxYZGWW3CO/ZznCRwdkO5Twuy I0vQyeGUjOil5RSggDVN/Xp4EzQSmk6WXmDn9D6BPO8z3R+PY3fx1jkNo8BSRuOahjNC vtzFeeUvNgsZtOG2JGu1xO0tRT5Qr8QZ56NMxPoOR7dLqjly8jgoa7QQln6dcbtMCjGW x/0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743868245; x=1744473045; 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=iHW+RJQCwOlwS8oi37rmV/vGmWyAPsKoXtE6S+wJuBE=; b=nYpLwSiTN6rGSBwIo2rQA8aubRsimEW8o+2wPIGBlaoGy4gfnPiTrekg93FJfKOF7S REGAEcj15YHzXokSz8HdFsLu3TZRnkEyz+wcPtmRPnVXcFTWNkk46/Q/9a2Y98KFUH2u CRvg7mwMpR/mN1geeiBuhIuYxNWEhoXpqrcWA2r2ICrrphruUIp1mQq7J0PSbt4Olpio UG5WnJuxNyebFPSS/tdAKyV11wbdRXHoj1fLtsXUEfmrOXeUQtqdp8R6AASiv/eggbbN +jmguEsj8ZcJZBQtEX7GPMgp7kF/wgKfArVgis0wKqRagJ1rAJW1X21xxhE+DvOkdA4j MPOg== X-Gm-Message-State: AOJu0YzIj4FFNCMOwdWaW2EPg5wpDDQkL5C5p/wyPbJ+AFxUS6x3B8KP fbSMbJ9zcyS5APAXn3RHoQputa9ewwt0SBrAd/7WP27gs5E8DlavWOzaBbLd+iRaSNrxDIjTVbu qkdAE8NuajOk6wCLfaPGcOUdq89QmDtU= X-Gm-Gg: ASbGncvbY5HjwFUidJQNfG7bex9HB0HcMjXJ6OTwogRkKxAPtfaQwwokaRlMSQf7RyN DD4IdQdHwRZTDrnJdLTFO2N5OwihuG3ltqrwne333fb0SBI9bfzFoB4uESHcAcG2sd3kikzymns qgC+e05KV1r0EEX1Bti2i78Kc2Y8i7h4MyyXnQyQTD15Q9/BGpN9bwndovbA== X-Google-Smtp-Source: AGHT+IG7EOXZAQptUJkF7TluqVzEQcGf03PhKICfhn6fxcZh65RLP+O82VWwff2L/jFrNZIsYqlaDBjYPg7PailMNRQ= X-Received: by 2002:a05:6402:4021:b0:5ee:498:7898 with SMTP id 4fb4d7f45d1cf-5f0b2b2b92dmr6541943a12.17.1743868244506; Sat, 05 Apr 2025 08:50:44 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 References: <2rq3bpvhclcipvgg3mo4gml7ysuzbvt6rfnzkprceumzeaeh4b@casrpprm6mgt> In-Reply-To: From: Rick Macklem Date: Sat, 5 Apr 2025 08:50:34 -0700 X-Gm-Features: ATxdqUERh86MtD4zeKOvf-VT2S6N4y6x7TkKUYEzNUmy8cZhCAU3cTaqwR_p5RU Message-ID: Subject: Re: Heads Up: commit 2ec2ba7e232d just hit main To: Shawn Webb Cc: FreeBSD CURRENT 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: 4ZVKgq64TTz4KW1 X-Spamd-Bar: ---- On Fri, Apr 4, 2025 at 6:27=E2=80=AFPM Shawn Webb wrote: > > On Sat, Apr 05, 2025 at 01:04:25AM +0000, Shawn Webb wrote: > > On Fri, Apr 04, 2025 at 05:40:21PM -0700, Rick Macklem wrote: > > > On Fri, Apr 4, 2025 at 10:50=E2=80=AFAM Shawn Webb wrote: > > > > > > > > On Thu, Apr 03, 2025 at 06:12:59PM -0700, Rick Macklem wrote: > > > > > On Thu, Apr 3, 2025 at 4:52=E2=80=AFPM Shawn Webb wrote: > > > > > > > > > > > > On Wed, Apr 02, 2025 at 01:51:26PM -0700, Rick Macklem wrote: > > > > > > > The commit 2ec2ba7e232d just hit main. I do not think it wil= l > > > > > > > cause problems, but it is fairly large. > > > > > > > > > > > > > > Man page updates will be done as separate commits. > > > > > > > > > > > > > > Hopefully this will not cause grief, rick > > > > > > > > > > > > Hey Rick, > > > > > > > > > > > > The patch review test plan mentions a patch to ZFS itself to su= pport > > > > > > named attributes. Is that patch available somewhere? > > > > > The ZFS patch is currently in phabricator as D49654. > > > > > Feel free to review it. > > > > > > > > > > It can also be found at: > > > > > https://people.freebsd.org/~rmacklem/zfs-xattr.patch > > > > > (this is a smaller diff which can be applied to an up-to-date mai= n src > > > > > tree easily) > > > > > > > > Hey Rick, > > > > > > > > I applied that zfs patch, but trying pathconf(2) on a file on a ZFS > > > > dataset with xattr=3Don (which seems to be the default) returns 0. = Am I > > > > doing something wrong? > > > > > > > > =3D=3D=3D=3D BEGIN LOG =3D=3D=3D=3D > > > > hbsd-current-01[shawn]:/home/shawn/tmp $ ./xattrtest xattrtest > > > > xattrtest: Named attributes not enabled: No error: 0 > > > > hbsd-current-01[shawn]:/home/shawn/tmp (1) $ zfs list /usr/home/sha= wn > > > > NAME USED AVAIL REFER MOUNTPOINT > > > > rpool/usr/home 10.4G 71.4G 9.85G /usr/home > > > > hbsd-current-01[shawn]:/home/shawn/tmp $ zfs get xattr rpool/usr/ho= me > > > > NAME PROPERTY VALUE SOURCE > > > > rpool/usr/home xattr on default > > > > =3D=3D=3D=3D END LOG =3D=3D=3D=3D > > > > > > > > That xattrtest application is yours from: > > > > https://people.freebsd.org/~rmacklem/xattrtest.c > > > No idea. It works for me. You used up-to-date kernel sources? > > > (Check that VIRF_NAMEDATTR is defined in sys/sys/vnode.h.) > > > Oh, and one more thing to check. zfs_xattr_compat needs to be non-zer= o. > > > (It's found in sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vnops_os= .c. > > > It's initialized to 1 and I don't see anything that sets it to 0?) > > > > It is indeed set to 1. > > > > > > > > The only thing I can think if is, if you changed xattr to on, you nee= d to > > > reboot (or at least remount) to get it to take effect. > > > (Maybe try setting it to "dir" and then reboot/remount. Maybe there i= s > > > a difference between "on" and "dir"?) > > > > Yeah, tried rebooting and still no go. Note that xattr defaults to > > "on" in FreeBSD by default. My src tree is synced up to FreeBSD commit > > 7e70d94acd68b3ac6b45f49d4ab7a0f7867c3ea7. I brought in the ZFS patch > > you linked to. > > > > > > > > Or, did you build zfs.ko some other way than as part of a kernel buil= d? > > > (It needs the patched .h files in the kernel sources, not something i= n > > > /usr/include/sys > > > that has not yet been updated.) > > > All the ZFS changes are #ifdef'd, since OpenZFS requires the sources > > > build for older kernels. (Basically #ifdef'd on that VIRF_NAMEDATTR m= entioned > > > above.) > > > > Perhaps I need to do a clean build. I'll try that and report back. > > > > > > > > It does remind me that I need to try a build of zfs.ko by doing a "ma= ke" in > > > the module directory. > > > > > > You can try the attached trivial patch and see if it spits out "pathc= onf ret=3D1" > > > on the console. > > > > I'll try that after a clean rebuild of the kernel. > > Clean rebuild didn't resolve it. However, I made some progress. > > I created a dataset specifically for this since I can't really unmount > my /usr/home dataset, so my example down below is a bit different than > the previous example I gave. > > The xattr property is set to "on" for the dataset. However, it's not > mounted with the xattr property. In order to get it to work, I had to > run the following commands: > > =3D=3D=3D=3D BEGIN LOG =3D=3D=3D=3D > $ sudo zfs umount rpool/scratch/xattr > $ sudo mount -t zfs -o xattr rpool/scratch/xattr /scratch/xattr > $ zfs get xattr rpool/scratch/xattr > NAME PROPERTY VALUE SOURCE > rpool/scratch/xattr xattr on local > $ mount | grep xattr > rpool/scratch/xattr on /scratch/xattr (zfs, local, noatime, nfsv4acls, na= med attributes) > $ mount | grep named > rpool/scratch/xattr on /scratch/xattr (zfs, local, noatime, nfsv4acls, na= med attributes) > =3D=3D=3D=3D END LOG =3D=3D=3D=3D > > So it looks like FreeBSD does not honor the xattr zfs property, > otherwise you would see a whole bunch of datasets mounted with the > "named attributes" flag in that last `mount | grep` command. I've looked at this a little more... There is a function xattr_changed_cb() that updates the xattr property information. It gets called when "zfs set xattr=3DXX " is done or when the mount option "xattr" is set. The question seems to be "Why was the stuff not correctly set for your file systems, although they show xattr=3Don?" Maybe I'll try and ask somewhere there are ZFS wizards or look in some OpenZFS commit logs. Have your ZFS file systems that do not have "named attribute" set been around for quite a while? (I'm thinking that they might have been configure= d differently when they were created and never changed.) It does look like the commands (done as root) should do the same thing as your umount/mount did. # zfs set xattr=3Doff # zfs set xattr=3Ddir I'll poke around and see if I can find out what the story is, rick > > -- > Shawn Webb > Cofounder / Security Engineer > HardenedBSD > > Signal Username: shawn_webb.74 > 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 Apr 5 15:52:06 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 4ZVKjb6btjz5sNgp for ; Sat, 05 Apr 2025 15:52:19 +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 4ZVKjb0s0Pz4Lj7 for ; Sat, 05 Apr 2025 15:52: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=EG0yRe86; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rick.macklem@gmail.com designates 2a00:1450:4864:20::52e as permitted sender) smtp.mailfrom=rick.macklem@gmail.com Received: by mail-ed1-x52e.google.com with SMTP id 4fb4d7f45d1cf-5e8be1bdb7bso4854541a12.0 for ; Sat, 05 Apr 2025 08:52:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1743868337; x=1744473137; 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=3JgJYB9nhRpMS8aVJH0RcR6IJMeXEI7SDLQsZyNiqWM=; b=EG0yRe86d870sP9arNuwuHu5NwNs2uVIVN/csQWEIh7+klt9b0WuaihhdcHEuPu5Rk 5bUNxVbg8dnUmi1/hbnMe1a0bdWZJipjVwjRKXuKLLQW+rJoSN2IrM6pHaF430oNrA/G dom7M4uzM1N+WxInuvUTql0lPoByFiWtk5eqjttnRAtLjJz2lLhzkFiLdttgZoyPts8a eWrlrXsOOin3a5HgxOf2IUXzNlmZg+ooGyXXrlOPeGEZIfooQ69p0g4pThGtl7UVxuEf eVPnaEIpsOaTZfEcRmmmgCd6iguV5PaDTA/DlwhV6rFiZU1/f1Xh8Ua4IZ5AlHnyl/K9 9cSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743868337; x=1744473137; 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=3JgJYB9nhRpMS8aVJH0RcR6IJMeXEI7SDLQsZyNiqWM=; b=oGMqsHBwdomYWTG+5hq+h6fa023QpBOavN6Q1ApbH5i7MHMePfIZyrbkrI1ZEiIOSO Rc0SX55v2i48Url3gMtgbdZrYAIdETuOzBESl14JIQ68AZC8l62W+6sEU8fCM6y/0Em9 FVLRTbB2RXfac6HNSXPt/ytFHvc2GirLneSviVVI0z3/4dQm6rPDo2BdruTJFouZ1Vw7 lspVry89CIn2MvpFRBJwlCqozPDMTgLKowqujVJwmZ2lkhhav+lCodMreAl+kL+Nw1JT LHngmfykwZmQiCYuHfva40zURT6v0Xm0y6qVcOTcm/+gITbvRy/VzXF5q50/WRk8ly6E 2H2Q== X-Gm-Message-State: AOJu0YyLtj8FYLwzrNoB/vzk+FlcpxwHySsiYjECgDabcjjWH8Uey9KA xnssn/e53T9W1ljp0s7kcrR8VuHVrtuds5QMaJp+SOTW1L046OlDOBuT592la4X5GZ03DsTew80 lZ/m9BUxtvvJe83nMdk2ryA4DnA== X-Gm-Gg: ASbGncvqCy++sZaszOa4vPKRgJU/P5Y4zttJIWqkjMQnjZDBj4x/zprTecctQJTu1AO TN9C4p9kK7jFd2V8REJ4zgLVwAixikRLTWOhx3khUpdQ+P993wGemu0I0sFtI2fzC/yn59bY7wr ufBAndoCrpC8JWxHNi4A/n3Z3BSnC4+KeEHGXtj8lKr+n17X3GKjpaNtP92w== X-Google-Smtp-Source: AGHT+IEdWt9SwHyTylP12ktdOsWg/LqOslgHNps1qsGnHAAPbZewmUpz5JN41nV3VVf/J65BF+rh+YusBXYutbTLKCU= X-Received: by 2002:a05:6402:430e:b0:5ed:61c8:adcf with SMTP id 4fb4d7f45d1cf-5f0db81a6b2mr2449782a12.15.1743868337070; Sat, 05 Apr 2025 08:52:17 -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: <2rq3bpvhclcipvgg3mo4gml7ysuzbvt6rfnzkprceumzeaeh4b@casrpprm6mgt> In-Reply-To: From: Rick Macklem Date: Sat, 5 Apr 2025 08:52:06 -0700 X-Gm-Features: ATxdqUFeVG9_VXQ2goLSbxtZCMFePLQ_XfojJ3HuEllO5ewEpnKugnkw8Hhg990 Message-ID: Subject: Re: Heads Up: commit 2ec2ba7e232d just hit main To: Shawn Webb Cc: FreeBSD CURRENT Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Result: default: False [-3.86 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.98)[-0.985]; NEURAL_HAM_MEDIUM(-0.87)[-0.873]; 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]; TO_DN_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; ARC_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; TAGGED_FROM(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+]; FROM_HAS_DN(0.00)[]; MISSING_XM_UA(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::52e:from] X-Rspamd-Queue-Id: 4ZVKjb0s0Pz4Lj7 X-Spamd-Bar: --- On Sat, Apr 5, 2025 at 8:50=E2=80=AFAM Rick Macklem wrote: > > On Fri, Apr 4, 2025 at 6:27=E2=80=AFPM Shawn Webb wrote: > > > > On Sat, Apr 05, 2025 at 01:04:25AM +0000, Shawn Webb wrote: > > > On Fri, Apr 04, 2025 at 05:40:21PM -0700, Rick Macklem wrote: > > > > On Fri, Apr 4, 2025 at 10:50=E2=80=AFAM Shawn Webb wrote: > > > > > > > > > > On Thu, Apr 03, 2025 at 06:12:59PM -0700, Rick Macklem wrote: > > > > > > On Thu, Apr 3, 2025 at 4:52=E2=80=AFPM Shawn Webb wrote: > > > > > > > > > > > > > > On Wed, Apr 02, 2025 at 01:51:26PM -0700, Rick Macklem wrote: > > > > > > > > The commit 2ec2ba7e232d just hit main. I do not think it w= ill > > > > > > > > cause problems, but it is fairly large. > > > > > > > > > > > > > > > > Man page updates will be done as separate commits. > > > > > > > > > > > > > > > > Hopefully this will not cause grief, rick > > > > > > > > > > > > > > Hey Rick, > > > > > > > > > > > > > > The patch review test plan mentions a patch to ZFS itself to = support > > > > > > > named attributes. Is that patch available somewhere? > > > > > > The ZFS patch is currently in phabricator as D49654. > > > > > > Feel free to review it. > > > > > > > > > > > > It can also be found at: > > > > > > https://people.freebsd.org/~rmacklem/zfs-xattr.patch > > > > > > (this is a smaller diff which can be applied to an up-to-date m= ain src > > > > > > tree easily) > > > > > > > > > > Hey Rick, > > > > > > > > > > I applied that zfs patch, but trying pathconf(2) on a file on a Z= FS > > > > > dataset with xattr=3Don (which seems to be the default) returns 0= . Am I > > > > > doing something wrong? > > > > > > > > > > =3D=3D=3D=3D BEGIN LOG =3D=3D=3D=3D > > > > > hbsd-current-01[shawn]:/home/shawn/tmp $ ./xattrtest xattrtest > > > > > xattrtest: Named attributes not enabled: No error: 0 > > > > > hbsd-current-01[shawn]:/home/shawn/tmp (1) $ zfs list /usr/home/s= hawn > > > > > NAME USED AVAIL REFER MOUNTPOINT > > > > > rpool/usr/home 10.4G 71.4G 9.85G /usr/home > > > > > hbsd-current-01[shawn]:/home/shawn/tmp $ zfs get xattr rpool/usr/= home > > > > > NAME PROPERTY VALUE SOURCE > > > > > rpool/usr/home xattr on default > > > > > =3D=3D=3D=3D END LOG =3D=3D=3D=3D > > > > > > > > > > That xattrtest application is yours from: > > > > > https://people.freebsd.org/~rmacklem/xattrtest.c > > > > No idea. It works for me. You used up-to-date kernel sources? > > > > (Check that VIRF_NAMEDATTR is defined in sys/sys/vnode.h.) > > > > Oh, and one more thing to check. zfs_xattr_compat needs to be non-z= ero. > > > > (It's found in sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vnops_= os.c. > > > > It's initialized to 1 and I don't see anything that sets it to 0?) > > > > > > It is indeed set to 1. > > > > > > > > > > > The only thing I can think if is, if you changed xattr to on, you n= eed to > > > > reboot (or at least remount) to get it to take effect. > > > > (Maybe try setting it to "dir" and then reboot/remount. Maybe there= is > > > > a difference between "on" and "dir"?) > > > > > > Yeah, tried rebooting and still no go. Note that xattr defaults to > > > "on" in FreeBSD by default. My src tree is synced up to FreeBSD commi= t > > > 7e70d94acd68b3ac6b45f49d4ab7a0f7867c3ea7. I brought in the ZFS patch > > > you linked to. > > > > > > > > > > > Or, did you build zfs.ko some other way than as part of a kernel bu= ild? > > > > (It needs the patched .h files in the kernel sources, not something= in > > > > /usr/include/sys > > > > that has not yet been updated.) > > > > All the ZFS changes are #ifdef'd, since OpenZFS requires the source= s > > > > build for older kernels. (Basically #ifdef'd on that VIRF_NAMEDATTR= mentioned > > > > above.) > > > > > > Perhaps I need to do a clean build. I'll try that and report back. > > > > > > > > > > > It does remind me that I need to try a build of zfs.ko by doing a "= make" in > > > > the module directory. > > > > > > > > You can try the attached trivial patch and see if it spits out "pat= hconf ret=3D1" > > > > on the console. > > > > > > I'll try that after a clean rebuild of the kernel. > > > > Clean rebuild didn't resolve it. However, I made some progress. > > > > I created a dataset specifically for this since I can't really unmount > > my /usr/home dataset, so my example down below is a bit different than > > the previous example I gave. > > > > The xattr property is set to "on" for the dataset. However, it's not > > mounted with the xattr property. In order to get it to work, I had to > > run the following commands: > > > > =3D=3D=3D=3D BEGIN LOG =3D=3D=3D=3D > > $ sudo zfs umount rpool/scratch/xattr > > $ sudo mount -t zfs -o xattr rpool/scratch/xattr /scratch/xattr > > $ zfs get xattr rpool/scratch/xattr > > NAME PROPERTY VALUE SOURCE > > rpool/scratch/xattr xattr on local > > $ mount | grep xattr > > rpool/scratch/xattr on /scratch/xattr (zfs, local, noatime, nfsv4acls, = named attributes) > > $ mount | grep named > > rpool/scratch/xattr on /scratch/xattr (zfs, local, noatime, nfsv4acls, = named attributes) > > =3D=3D=3D=3D END LOG =3D=3D=3D=3D > > > > So it looks like FreeBSD does not honor the xattr zfs property, > > otherwise you would see a whole bunch of datasets mounted with the > > "named attributes" flag in that last `mount | grep` command. > I've looked at this a little more... > There is a function xattr_changed_cb() that updates the xattr property > information. > It gets called when "zfs set xattr=3DXX " is done or when > the mount option "xattr" is set. > > The question seems to be "Why was the stuff not correctly set for your fi= le > systems, although they show xattr=3Don?" > Maybe I'll try and ask somewhere there are ZFS wizards or look in some > OpenZFS commit logs. > > Have your ZFS file systems that do not have "named attribute" set been > around for quite a while? (I'm thinking that they might have been configu= red > differently when they were created and never changed.) > > It does look like the commands (done as root) should do the same thing > as your umount/mount did. > # zfs set xattr=3Doff > # zfs set xattr=3Ddir Oh, and followed by a reboot or umount/mount without the xattr mount option= . > > I'll poke around and see if I can find out what the story is, rick > > > > > -- > > Shawn Webb > > Cofounder / Security Engineer > > HardenedBSD > > > > Signal Username: shawn_webb.74 > > Tor-ified Signal: +1 303-901-1600 / shawn_webb_opsec.50 > > https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb= /03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc From nobody Sat Apr 5 16:07:58 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 4ZVL3z4wN6z5sPlc for ; Sat, 05 Apr 2025 16:08:15 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-20.consmr.mail.gq1.yahoo.com (sonic306-20.consmr.mail.gq1.yahoo.com [98.137.68.83]) (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 4ZVL3x6qQGz4PYD for ; Sat, 05 Apr 2025 16:08:13 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=cZsAzRrF; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1743869292; bh=hGdZCgjVkBCclY6YybJdYSG67H67rqYlmUeiZ7HWNxY=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=cZsAzRrFIOnSx2JiuTzqJAtFOBbiJwIH13LfiG78dS/6cqmiFiyJ4G3otPjSHAyzWWt9PBl8Td4bO0+ou5x54DErjeUh/kzaGtrXZJpDSjIV11oP5P7nIC6297K2TYoK4cmHnFH05c3Q0uOI3ejbUM24QHRVgEkdAKiasPLdCfwfiVCsz5hQNeLg7ydmv0IJIgUoCv0k5HyUL/CSGFsC0u8NHq6Jkce+5vMiWYU+nk/GMub09UrDn3Fuk0jV6XYjR1PClTjPa7Wb6uBp7vK423Op1E/xoZAGnlcYg6PHxSDRNs9AtgiwJULIio2g/6EEJY4kQOXzgJiatW+0AY4qXg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1743869292; bh=Wq50PtSB8wJKBFnF8leN3EpkR0H2v6U0mp0SAIvnAa2=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=akkdNLYuhNnIVbcH1vmi9i5644bYbmIgKOMiUjuEwyzg0u/cTiDcXTcFjg5EehefF+WR05ohWb49YwcHVQU1raJgIDdcvLlQpLdCpcfc9F8NllPN9BLnRGPyIn9wDtasLFtBmq+i8fSFuaiFYoGbwzicVOJNSq0DpW7iBTUck0uBVPzqXAtBDV3byFKOvGemc+kxw/MSW5MQ4TzN+KbZAqbR+yJl6z3WYFTrVAnPvCfWAufffQ0SMxunBJc28+dcdEgsc40iPZTCEQkr4WhmfvzqG+Wqqip5/xynQMawzkHeDO+dMiIIQuocJBUVXUGsPV0JONiPN5VKmE0J8v3eHg== X-YMail-OSG: UQ0JoxYVM1nsFJqQt1GApw07ty.B9lPlGXkSq8v6dZV6zeqEiquQhSYmj6b9l_H 8p2FC8gDyOOOqungwkUvIirwL3CAglQRaa6Q.cLHZxpmUDLVa_lTeVXe0TlSoSjCkOM9xx7IA9BH Xi3jM4TKGDZZrKdk8Qj0RA7Ar9gmFMs1sR5CHMSrmDrJMcwzEfUUjmH2OQdC1poWYVsMUmz7za.5 lw8cwBHKkOsfsQIZLGxoSVO6aeA4VNfDF7344OJYrHepbEm9_HXld3bp0cWNb07ceTg5wSu0iXT5 kDSz7WRl5ZlRuRv1ZO88kIV9u7igXs.WtEoN1ajLEWzHaaAaEc7krGBpSI3LRTzlB4CufP8PpVFZ uii98e6WRr7sA7bF1F86nIxrUGHT2DD.Nof4rscpoKMSYLt_dZm5nKRXbliFciy.MvwvsrUmN.9o mhNQQU9Xb9n_YCh2URMbvkG3FVX615xQOKzNFstrIJG6W0DoySRxnKhOYWWq.dhgPA0TMxXPiiPT kP7jhgFrKg6z0SdtqHeoRCRyGgz8aC.hZMkvWrdxtyvlFtKgI2_ZTKr3AUElhFbKOGTgve9fL2i9 aMK56uv3gFdHu0pskqhv0rsS9gHzHGQdvjm2I0DM1PzF67gRgdyPHbeobZAx.RsZRMCWq.jtiEkR 2kcldpBP06efqSxktEkB8fNIRQYE5SOzOlv3MdSl0oMVRrDD2cxHreT3zmFC1Fh9vG18U_cwkTsj DQaCloi_WVY2XpyoxwV5VH09KjCJB.S.dIih02mzEGWCeFSCV8PqD.I67ZT4tHE3m1W0fCmUraLu wZB0dMzShyb7BY812lTs.kOPQb6Rp4sbzWLok7VTfFwrQxeKgLaxlOJWspb1nzF.7fDRuv9UAwwh 2JCRLwqqbBk6yRA_V0afJ_uX91lxxpVKvckl4lju7e027JLyKShUkEavvKp1mY90UZTD9tvYAZbj eh7CYn6EOlhn9pd6eYq8dzoC73C5yExeumAyRejuZu3CyVwl.KdF16r0uaj.JkAP5YVimj7dVF5r IW5xZY1JGLgcdPX7RWZxyFcBFkSzznSNEer4gbO3xEvsCurvHd9GAL7wkM6BQeEl4bPttgZAPunS dLOsrzD8MwXBMYy6P3011H1kFpqlED8Cy4GxufGxAxnSw2mmoTnwGDZj20TWcdWQvg1fHtGwKNXR OojbWverUxg2B1ljltbDOywTbCXshh7eM4H1h4JowLCuT_fqqPWpeZLIvXGEa6OodmAZl0n3pwoF yqblG69aftwTmqeicfloFiY.k_CtWFulW844OZ6XgLV8KFTvAD5GQ6nxliLf2gF2FmbK5YmqsAOT R69nAo3DncmDlRDFQH3oVZsJp98ekLObltZ2AisC9sNnFE8BJHr0K1gWcba6XsZd3awvUO2FkF5W HnWZpYiD.2c2RsQ6_Q6ajJUL8lptoeV73e732pCdhf4hQZGk0yK_yMUFITwRm.wTUjNF_wATlLPt aXRkBZjr.8I7.CVhMH1gDunVClPyRQbY6mbT1S8MInPkWLgGHfK5kbbflui.t9GViAqSL6Z5f1G2 FqqNqIZi8f_TkBbHtGRzqRDeSHxgPHgnCTqFvbXGPWO3FV1.zCIB_Nsc8p2I8.f9bh84_NJeQwmP 5ON38_JaN9Ara6fFlKFy6aGzK3gfRHUqe1WHH_4OwV6.9xdScfpPy0fQc0xHRGFAPeKgUwysdvS. Cva76y3Ru9CIRUkxZ1_LADMDreXC5ZKNd5JEtyH.bZoF9ggDgjWeDvG7AA.zF5hUBU.sc3FATc4h VdAKgbr54DMv.eUQn9rjJFgstDDqhXFxgM1JRKQhNB3dqPdC9sduwibE9qjSGVTtgC5Zj3kHZdmq H_fqwV0uiwSDhJKz8xEbjIKu7HSJf8hzbcR8EmtsUSGbWNW1.pUhx4VFDxnsUf5VQfbbj.VFjPUE Qw0V2wLoG3zV9Su19rQvL7fOfu.mj5WI0XBcZRs04SGpnztGoVcglPOitMrQN7zLTMNxr.qW5k4V d5W_ioYAwIeXxGJPPOH_rCW86skwUvU78fcwhsPz0kKahu2Y12F3lAcGVFSjigcyehy5.sTCaHTI 26rEriybUkA5aER4l0pWHOoiGSvi23DY9CZjRPGHV2SjuWhPq7aSgHy9sFnVNxA8SyuPDDUgwQmw nrFeZscoyyyqNNAia7fr6.FwtPDL8Az_i9QWWRJWSghhqAOvurkxhkps9DPZiCAQXMyHgogpzoFV LfbR9aIh8m2aebhFMf2GMxPAIRfB9XkQWYJxZQzr2JHbiMDDG0XG0aUx0vM2tr9hyhVjswLxSQvf pVkq8vA-- X-Sonic-MF: X-Sonic-ID: 3fb0b684-78da-46e4-8255-559cf6027c0d Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Sat, 5 Apr 2025 16:08:12 +0000 Received: by hermes--production-gq1-5c477bf655-pf5cp (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID bf995e226e9601565523cd90d7ff9417; Sat, 05 Apr 2025 16:08:09 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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.500.181.1.5\)) Subject: Re: Samsung T7 external SSD support? Date: Sat, 5 Apr 2025 09:07:58 -0700 References: To: kargls@comcast.net, FreeBSD Current In-Reply-To: Message-Id: <5331211E-9FD6-4E60-873B-729BD04A40EC@yahoo.com> X-Mailer: Apple Mail (2.3826.500.181.1.5) X-Spamd-Result: default: False [-3.40 / 15.00]; RBL_SENDERSCORE_REPUT_9(-1.00)[98.137.68.83:from]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.90)[-0.901]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; TO_DN_SOME(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; FREEMAIL_TO(0.00)[comcast.net,freebsd.org]; FREEMAIL_FROM(0.00)[yahoo.com]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.83:from]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.83:from] X-Rspamd-Queue-Id: 4ZVL3x6qQGz4PYD X-Spamd-Bar: --- [Attempting to send to the right FreeBSD list this time.] On Apr 5, 2025, at 09:02, Mark Millard wrote: Steve Kargl wrote on Date: Sat, 05 Apr 2025 01:45:53 UTC : > Anyone using a Samsung T7 external SSD with FreeBSD current? > > If I plug the drive into a USB 2.0 port, I see > > usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage device > Samsung PSSD T7 Shield (0x04e8:0x61fb) > ugen0.2: at usbus0 > umass0 on uhub1 > umass0: on > usbus0 > umass0: SCSI over Bulk-Only; quirks = 0x0100 > umass0:5:0: Attached to scbus5 > da0 at umass-sim0 bus 0 scbus5 target 0 lun 0 > da0: Fixed Direct Access SPC-4 SCSI device > da0: Serial Number S6NPNS0Y201077Y > da0: 40.000MB/s transfers USB2 port connections always show <= 40 MiByte/sec. Maximums: USB 2.0 High Speed 480 Mbps USB 1.1 Full speed 12 Mbps USB 1.0 Low speed 1.5 Mbps It does not matter if the USB device supports any of the faster USB3+ speeds: USB 3.0 SuperSpeed 5 Gbps (FreeBSD reports 400 MiByte/sec) USB 3.1 SuperSpeed/Gen1 5 Gbps (FreeBSD reports 400 MiByte/sec) USB 3.1 SuperSpeed+/Gen2 10 Gbps USB 3.2 SuperSpeed+/Gen2 10 Gbps USB 3.2 SuperSpeed+/Gen2x2 20 Gbps (requires USB-C) USB4 10Gbps/Gen2x2 10 Gbps (requires USB-C)? USB4 20Gbps/Gen2x2 20 Gbps (requires USB-C) USB4 40Gbps/Gen3x2 40 Gbps (requires USB-C) USB4 80Gbps/Gen3x2 80 Gbps (requires USB-C) Note: FreeBSD never reports more than 400 MB/sec in the "da*: * MB/s transfers" messages. The figure shown is not based on measurement. I do sometimes have connections that normally report 400 MB/sec (so: 5 Gbps mode use) instead report 40 MiByte/sec (so: USB 2.0 480 Mbps mode used instead). So far as I know, FreeBSD has no explicit support for enabling use of any 10+ Gbps modes. FreeBSD support for USB4 varies based on if the likes of UEFI/ACPI handles various things when the kernel does not: FreeBSD does not have all the kernel software that would be required. So it does not disable the UEFI/ACPI handling. Even when UEFI/ACPI or the like handles various things, and so enabling some USB4 use, there may be issues with hot-unplugging and/or hot-plugging USB4 connections. > da0: 1907729MB (3907029168 512 byte sectors) > da0: quirks=0x2 > > However, the SSD is supposedly a USB 3.2 gen 2 device with a ~1000 MBps > read/write speed. https://semiconductor.samsung.com/us/consumer-storage/portable-ssd/t7-touch/ reports in the "*" footnote: "To reach maximum read/write speeds of up to 1,050/1,000 MB/s, respectively,the host device and connection cables must support USB 3.2 Gen 2 and the UASP mode must be enabled." FreeBSD does not support UASP mode use: just "SCSI over Bulk-Only". So do not expect 1,050/1,000 MB/s even if everything else about the hardware environment could support it. (Such consequences for lack of UASP is not unique to the T7 Touch.) > When plugged into a USB 3.x port, I typically see > > ugen0.2: at usbus0 > > and the device is not listed with usbconfig. Repeatedly, unplugging the > ssd and re-plugging it into the USB 3.x port, I eventually get the above > dmesg output. Seems like a possible cable / signal integrity problem. In my use of T7 Touches some hosts are picky about which type of cable I use. For 2 of them, the pre-supplied cable does not work reliably. But the cables that work for those, do not generally work well elsewhere. ". . . the internal resistance and maximum allowable current can vary depending on which type of cable you are using." > Do I need a quirk for this SSD to get recognized? I've never had to adjust the quirk status. But on some RPi*'s I've had to have U-Boot use usb_pgood_delay adjustments to reliably boot. (An issue that happens before even the FreeBSD loader is involved.) > Also, > shouldn't it connect with faster transfer rate than 'da0: 40.0MB/s'? See earlier notes above. === Mark Millard marklmi at yahoo.com === Mark Millard marklmi at yahoo.com From nobody Sat Apr 5 16:12: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 4ZVL9N1QTwz5sPyb for ; Sat, 05 Apr 2025 16:12:56 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (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 4ZVL9M2m7xz3CFM for ; Sat, 05 Apr 2025 16:12:55 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=hardenedbsd.org header.s=google header.b=jP2TtcOA; dmarc=none; spf=pass (mx1.freebsd.org: domain of shawn.webb@hardenedbsd.org designates 2607:f8b0:4864:20::d34 as permitted sender) smtp.mailfrom=shawn.webb@hardenedbsd.org Received: by mail-io1-xd34.google.com with SMTP id ca18e2360f4ac-855bd88ee2cso72652339f.0 for ; Sat, 05 Apr 2025 09:12:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd.org; s=google; t=1743869573; x=1744474373; 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=2F0pHWLgpf3mosgmlHncGpHjbkslKKV1Q5caNZM7Qmg=; b=jP2TtcOAK6z5elr/3aYXqBuPccENCi4irrx81e7WvP4qMzx8Fmuhn44+Uv0K0S95MV ZLFY2erj8hLbAEdfSWJQdgVp87Rk6YRYOMKORgAqNKjgGDzQLJbjRtnEBM0hukktZmLk gnOcXJVFyEn8Xw2nWXxf3aYX6zzwPY/DQJXcyqrBhIN8sLobs1Mpg6hGOF0yUT91XbuE cL5uCPYBGyaujuHCnLyGrDyOzkirgwslJupiNA+2wwzOb7bZ9ZTn9yNQW4zHbnPm8wvF UbLB3Qu2Bs19EPv1MwGoPTnIMRjuknISnvf6uC9X66zpqZxAHeZahY5MVX3nzTWeIZE3 EhKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743869573; x=1744474373; 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=2F0pHWLgpf3mosgmlHncGpHjbkslKKV1Q5caNZM7Qmg=; b=mtiSwe6YQpR5joIFbqcS5XEpUp+hAP+P4IYfAdDLmnzvheDuk8khnFFhD3WRMhzlOB rP7X7LPV8UTUCphjWupC6JoQt8LUvLWDxLo5KBRHzoKNxCXdUQUVsy8vfo/5mAXHwpI5 IW4cJT04SwNjXthaPorB5XfIG+6+q9my70SlSLcwWvW1nliSRIAVYL6UhmFZ0ajO4ChK OqsoDdqcAmoBbDA5/Cs9UfR7V2fMRnGdMmztlrWnbVPAvtkpaqyW4vWaybh9Fhxe4nzq tpFvvbYRBNtbElkdIgH/v04DOCXOX9rVzsLLXqSWku3WHLQTMVg9C7rmA07cF4uqL13z 9uNw== X-Gm-Message-State: AOJu0YzteZRd3Hi5CYZzYg393PLeedt3KKAs5ry3JKaMDNguTJNKOVFf k5tNR8DT4Goae93e2GleUdUGaleQIU9FAVgM4yOxsIZ/02DL0X99aJVOclyOPY4= X-Gm-Gg: ASbGncvIEM2+avGapqi/5h9zweAr4rkMXLjavTVIixOY5hXavukXERPuezm0NN8axak qzRW1a3+smSnGIY+LEokmWSCRRm4GVevwWNcQTjbQD/KWbjGOtfmVfya8nzNGR3sulbm8EHXA6C GrlgeK4kbSptoxHQ7MHUuY7CqNcbPA20a/wdAFo+oQNKUG0e8b5pXgcKyGqC3hEa42JarbERGUd 2Dt5pSLwmth0+X+JhXRAotD8BrUsChlLPlYWgwHn1sBHoLc0CfEg8KuzhCVhAd+MfdCp4s4yxsY ccTJm/JHyAT9fjg26BpDaH9GQhqOZZ/SM1IMjg== X-Google-Smtp-Source: AGHT+IGUJQKTnZBidg0kqCHu+IVebrfiCU1EZY6Ln4OPRpTlJZC5HtLn/j/tdcnKi78vpfmaYVNuRw== X-Received: by 2002:a05:6e02:1485:b0:3d0:443d:a5c3 with SMTP id e9e14a558f8ab-3d6ec525413mr35306715ab.3.1743869573321; Sat, 05 Apr 2025 09:12:53 -0700 (PDT) Received: from mutt-hbsd ([2001:470:4001:1::95]) by smtp.gmail.com with ESMTPSA id e9e14a558f8ab-3d6de79f182sm14185875ab.4.2025.04.05.09.12.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 05 Apr 2025 09:12:52 -0700 (PDT) Date: Sat, 5 Apr 2025 16:12:51 +0000 From: Shawn Webb To: Rick Macklem Cc: FreeBSD CURRENT Subject: Re: Heads Up: commit 2ec2ba7e232d just hit main Message-ID: <4beaxy5dpajikvafxpjogcxrpyuwwicng5ln5rxbxlbzp2o2g7@ib7wo5jzlte4> 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: <2rq3bpvhclcipvgg3mo4gml7ysuzbvt6rfnzkprceumzeaeh4b@casrpprm6mgt> 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="d3gnhrcqmofn7d2v" Content-Disposition: inline In-Reply-To: X-Spamd-Result: default: False [-5.04 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.94)[-0.935]; MID_RHS_NOT_FQDN(0.50)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; R_DKIM_ALLOW(-0.20)[hardenedbsd.org:s=google]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; RCPT_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[hardenedbsd.org:+]; ARC_NA(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; DMARC_NA(0.00)[hardenedbsd.org]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MIME_TRACE(0.00)[0:+,1:+,2:~]; 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::d34:from] X-Rspamd-Queue-Id: 4ZVL9M2m7xz3CFM X-Spamd-Bar: ----- --d3gnhrcqmofn7d2v Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: Heads Up: commit 2ec2ba7e232d just hit main MIME-Version: 1.0 On Sat, Apr 05, 2025 at 08:52:06AM -0700, Rick Macklem wrote: > On Sat, Apr 5, 2025 at 8:50=E2=80=AFAM Rick Macklem wrote: > > > > On Fri, Apr 4, 2025 at 6:27=E2=80=AFPM Shawn Webb wrote: > > > > > > On Sat, Apr 05, 2025 at 01:04:25AM +0000, Shawn Webb wrote: > > > > On Fri, Apr 04, 2025 at 05:40:21PM -0700, Rick Macklem wrote: > > > > > On Fri, Apr 4, 2025 at 10:50=E2=80=AFAM Shawn Webb wrote: > > > > > > > > > > > > On Thu, Apr 03, 2025 at 06:12:59PM -0700, Rick Macklem wrote: > > > > > > > On Thu, Apr 3, 2025 at 4:52=E2=80=AFPM Shawn Webb wrote: > > > > > > > > > > > > > > > > On Wed, Apr 02, 2025 at 01:51:26PM -0700, Rick Macklem wrot= e: > > > > > > > > > The commit 2ec2ba7e232d just hit main. I do not think it= will > > > > > > > > > cause problems, but it is fairly large. > > > > > > > > > > > > > > > > > > Man page updates will be done as separate commits. > > > > > > > > > > > > > > > > > > Hopefully this will not cause grief, rick > > > > > > > > > > > > > > > > Hey Rick, > > > > > > > > > > > > > > > > The patch review test plan mentions a patch to ZFS itself t= o support > > > > > > > > named attributes. Is that patch available somewhere? > > > > > > > The ZFS patch is currently in phabricator as D49654. > > > > > > > Feel free to review it. > > > > > > > > > > > > > > It can also be found at: > > > > > > > https://people.freebsd.org/~rmacklem/zfs-xattr.patch > > > > > > > (this is a smaller diff which can be applied to an up-to-date= main src > > > > > > > tree easily) > > > > > > > > > > > > Hey Rick, > > > > > > > > > > > > I applied that zfs patch, but trying pathconf(2) on a file on a= ZFS > > > > > > dataset with xattr=3Don (which seems to be the default) returns= 0. Am I > > > > > > doing something wrong? > > > > > > > > > > > > =3D=3D=3D=3D BEGIN LOG =3D=3D=3D=3D > > > > > > hbsd-current-01[shawn]:/home/shawn/tmp $ ./xattrtest xattrtest > > > > > > xattrtest: Named attributes not enabled: No error: 0 > > > > > > hbsd-current-01[shawn]:/home/shawn/tmp (1) $ zfs list /usr/home= /shawn > > > > > > NAME USED AVAIL REFER MOUNTPOINT > > > > > > rpool/usr/home 10.4G 71.4G 9.85G /usr/home > > > > > > hbsd-current-01[shawn]:/home/shawn/tmp $ zfs get xattr rpool/us= r/home > > > > > > NAME PROPERTY VALUE SOURCE > > > > > > rpool/usr/home xattr on default > > > > > > =3D=3D=3D=3D END LOG =3D=3D=3D=3D > > > > > > > > > > > > That xattrtest application is yours from: > > > > > > https://people.freebsd.org/~rmacklem/xattrtest.c > > > > > No idea. It works for me. You used up-to-date kernel sources? > > > > > (Check that VIRF_NAMEDATTR is defined in sys/sys/vnode.h.) > > > > > Oh, and one more thing to check. zfs_xattr_compat needs to be non= -zero. > > > > > (It's found in sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vnop= s_os.c. > > > > > It's initialized to 1 and I don't see anything that sets it to 0?) > > > > > > > > It is indeed set to 1. > > > > > > > > > > > > > > The only thing I can think if is, if you changed xattr to on, you= need to > > > > > reboot (or at least remount) to get it to take effect. > > > > > (Maybe try setting it to "dir" and then reboot/remount. Maybe the= re is > > > > > a difference between "on" and "dir"?) > > > > > > > > Yeah, tried rebooting and still no go. Note that xattr defaults to > > > > "on" in FreeBSD by default. My src tree is synced up to FreeBSD com= mit > > > > 7e70d94acd68b3ac6b45f49d4ab7a0f7867c3ea7. I brought in the ZFS patch > > > > you linked to. > > > > > > > > > > > > > > Or, did you build zfs.ko some other way than as part of a kernel = build? > > > > > (It needs the patched .h files in the kernel sources, not somethi= ng in > > > > > /usr/include/sys > > > > > that has not yet been updated.) > > > > > All the ZFS changes are #ifdef'd, since OpenZFS requires the sour= ces > > > > > build for older kernels. (Basically #ifdef'd on that VIRF_NAMEDAT= TR mentioned > > > > > above.) > > > > > > > > Perhaps I need to do a clean build. I'll try that and report back. > > > > > > > > > > > > > > It does remind me that I need to try a build of zfs.ko by doing a= "make" in > > > > > the module directory. > > > > > > > > > > You can try the attached trivial patch and see if it spits out "p= athconf ret=3D1" > > > > > on the console. > > > > > > > > I'll try that after a clean rebuild of the kernel. > > > > > > Clean rebuild didn't resolve it. However, I made some progress. > > > > > > I created a dataset specifically for this since I can't really unmount > > > my /usr/home dataset, so my example down below is a bit different than > > > the previous example I gave. > > > > > > The xattr property is set to "on" for the dataset. However, it's not > > > mounted with the xattr property. In order to get it to work, I had to > > > run the following commands: > > > > > > =3D=3D=3D=3D BEGIN LOG =3D=3D=3D=3D > > > $ sudo zfs umount rpool/scratch/xattr > > > $ sudo mount -t zfs -o xattr rpool/scratch/xattr /scratch/xattr > > > $ zfs get xattr rpool/scratch/xattr > > > NAME PROPERTY VALUE SOURCE > > > rpool/scratch/xattr xattr on local > > > $ mount | grep xattr > > > rpool/scratch/xattr on /scratch/xattr (zfs, local, noatime, nfsv4acls= , named attributes) > > > $ mount | grep named > > > rpool/scratch/xattr on /scratch/xattr (zfs, local, noatime, nfsv4acls= , named attributes) > > > =3D=3D=3D=3D END LOG =3D=3D=3D=3D > > > > > > So it looks like FreeBSD does not honor the xattr zfs property, > > > otherwise you would see a whole bunch of datasets mounted with the > > > "named attributes" flag in that last `mount | grep` command. > > I've looked at this a little more... > > There is a function xattr_changed_cb() that updates the xattr property > > information. > > It gets called when "zfs set xattr=3DXX " is done or when > > the mount option "xattr" is set. > > > > The question seems to be "Why was the stuff not correctly set for your = file > > systems, although they show xattr=3Don?" This is indeed what I was inferring. xattr has been set to "on" since the pool's creation as far as I can tell. Until experimenting with your patch, I didn't really even know the xattr property even existed. > > Maybe I'll try and ask somewhere there are ZFS wizards or look in some > > OpenZFS commit logs. > > > > Have your ZFS file systems that do not have "named attribute" set been > > around for quite a while? (I'm thinking that they might have been confi= gured > > differently when they were created and never changed.) > > > > It does look like the commands (done as root) should do the same thing > > as your umount/mount did. > > # zfs set xattr=3Doff > > # zfs set xattr=3Ddir > Oh, and followed by a reboot or umount/mount without the xattr mount opti= on. The ZFS pool in the VM I'm testing was created in 2020. I would have thought that the datasets would be mounted with "named attribute" support by default since the xattr attribute is set to "on" for every single dataset. A reboot does not cause the datasets to be mounted with "named attribute" support. I had to unmount the dataset manually, then run that `mount -t zfs -o xattr ...` command manually. I suspect that the dataset automounting code paths, as performed at boot time, might need to be updated. I have zero experience with ZFS code, so my suspicion could be completely incorrect. =46rom a user's perspective, it seems that the xattr property is ignored when ZFS automounts a dataset on FreeBSD. That behavior is what is causing my suspicion above. Thanks, --=20 Shawn Webb Cofounder / Security Engineer HardenedBSD Signal Username: shawn_webb.74 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 --d3gnhrcqmofn7d2v Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEA6TL67gupaZ9nzhT/y5nonf44foFAmfxVnwACgkQ/y5nonf4 4frCSA/8CC2mTgLbTOegJhHX2rBM5E/DC6CnVcnI7HYlclqK44WgwOLX7YqQq81b 6LdqPHaws/x/f9+/Bnh5GWk6GxYyCvVQ7WxTowrjlLLeC4xnqRabNLny/ODppjyy Kp7uRCXVhRIK8e3ogknMgGVlE/evHrO+eduwCtsuAMlTXGgV6OPNzPIRQIquKANF 4uykMBFFd1pfWBOx74pcE4YuOAp3CkVuhntWBoHf7LUb5lIS8N/8BXYwP8CpVP3p j9XX43oXBzgYej6+y0cACTWxpoIhfg2ehkAqLB4MAsfHVN+wXdNnFcTTSRS/9X83 4upMHa44eE+ZtfozutngVh4sIgmMxr8sQ8NysXVVJTw82RCR1dQLudH7g9CG2B54 pU6sxkWUhrjI55Mnioq4bzBs/CnyQwf0zXp5fafiv3LFDFLmzaPvVTwlcSK3Di0b G8Chq0HQMx4P1fb/Xuv6AW6DckbEfFv5zHgG0D+sEe5307FkR9pI3qkjMa7GAW0L ZhU6Wta+fTHOOiyJ1Cy1cstfn0Vdh+jS6E1IpySfUwPn6dcFpv7VadPc+WVNm+CK f7nisVlvfguISeVjysAPIUEkbhgdWHtpTY+yjgpktLmUou2i32llgfXBwtHCVNjy JPfyoLKDXIjUOjJaxJQTWTXCM3aOLPfoSQ6IBgGQcmLlctY3Fg4= =uU3w -----END PGP SIGNATURE----- --d3gnhrcqmofn7d2v-- From nobody Sat Apr 5 23:12: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 4ZVWTR6qP5z5sV3r for ; Sat, 05 Apr 2025 23:12:27 +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 4ZVWTR2MB6z3dkX for ; Sat, 05 Apr 2025 23:12:27 +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-5e5e22e6ed2so4700106a12.3 for ; Sat, 05 Apr 2025 16:12:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1743894746; x=1744499546; 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=yVnlZOs7PkSS8+cqpMechgMBgOFumU3IYOQ3kMG+LCs=; b=ErgD0F6LzDf0hszncXnmE2LqGpEefu9uhmKROg+S06HK6daDd/pFftXxsqxMkYNgcu HhLVFMs5+F6MovDOCbdTsgCjsFkxZZ2tv4YjmdAbX3KzJ7eZFgKAumx4+1rCcWeUaogm dEcWooi3XjwPHB7FztVpK+qb+qO1XbSjUrXh0kss0CKRPMxK9fVmhtKOndGpevXzrRen wARaZFVvy9gTuQxS8Q9YLa3yb3P6SgVfzT+27kM/oYGlmJS8buF9yZX7XCb4G/ocaAIr lroX6WeouMlDnWburYcgmlhAfKYFr26G24IQ9OiOGPHRHOMhQ4xIalZxMUSC281aOPVB bGLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743894746; x=1744499546; 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=yVnlZOs7PkSS8+cqpMechgMBgOFumU3IYOQ3kMG+LCs=; b=QY9RuLqnMs4trigtqgC12dvdKLITs7HmWnGdS7tu4RxgeCekxwFsIVonsQstmTUkM2 6OGm64f3bc9VV8DLjsZ+x1tnPkhcrJ1/AlsDD4rn3fLV1FFlkEzfhJABMW1jmODGsQR4 BFC20shLUxgY5a1POPjBh0G9Gj5zFNHBI5jnffXBJy0nnTeS3VgjcSapQMjmW1UKub8v hSPvJ/9iogX+lGd4M2r8ee2AwKxhy8Eq7hOn9S1BR++0WZWrmdpisc49ol8zxDwgbohi mRfPAHYm1OqdTBnP9Vi2jn8sZjjNxCcV6sOPj7hrLUiWM4++mvAAHZf5vy0MfCAQ4Iqu bCJQ== X-Gm-Message-State: AOJu0YycVsuSk+ixxlyEinTNuuWLYL3ONEaZGPfNmSrnAM5lrlLE4p5K 5AfsVz+HVk4NNFnDSHG6n1IPgdmJR9nvTk0qKCU5la8OlGksWKFLQROMyjCxs24qCwikUujQyB7 sbiIKRSVTvPaRHPQ6M9WHUnOsbQ== X-Gm-Gg: ASbGnctLowJavR1kvwir+C8nOFEflsCzh5SglcjlubmtJhH97GBZvB1YBkwyMdOeQFo GwDL+powotBmaAMT2NFs6syrtGnbkIz4ZERG+MsdevA366pKFICvQcLNBCmK6dIW4+8mzzyak9s Wi41S0oktUMHOa37Z2Ewfy1pUoTSzgM67qwP4lOFrVXMsTRpk2dRyRz5U5 X-Google-Smtp-Source: AGHT+IF/7f/s8KSg1M6Hb/dTjotUBzCdHM806hZz4VfEFHj4pUxtd6dl5Rl2/cWzIG0BmlIr6NCD6SR5lKrud0w7F8Q= X-Received: by 2002:a05:6402:40c6:b0:5ed:1444:7914 with SMTP id 4fb4d7f45d1cf-5f0b6630aa0mr6928783a12.28.1743894745605; Sat, 05 Apr 2025 16:12:25 -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: <2rq3bpvhclcipvgg3mo4gml7ysuzbvt6rfnzkprceumzeaeh4b@casrpprm6mgt> <4beaxy5dpajikvafxpjogcxrpyuwwicng5ln5rxbxlbzp2o2g7@ib7wo5jzlte4> In-Reply-To: <4beaxy5dpajikvafxpjogcxrpyuwwicng5ln5rxbxlbzp2o2g7@ib7wo5jzlte4> From: Rick Macklem Date: Sat, 5 Apr 2025 16:12:15 -0700 X-Gm-Features: ATxdqUHx3Hkhbl65gkbQDAz9-pAFgZtDfdrmMTL00EgFC5TMBNFyCU13iLbqU_k Message-ID: Subject: Re: Heads Up: commit 2ec2ba7e232d just hit main To: Shawn Webb Cc: FreeBSD CURRENT 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: 4ZVWTR2MB6z3dkX X-Spamd-Bar: ---- On Sat, Apr 5, 2025 at 9:12=E2=80=AFAM Shawn Webb wrote: > > On Sat, Apr 05, 2025 at 08:52:06AM -0700, Rick Macklem wrote: > > On Sat, Apr 5, 2025 at 8:50=E2=80=AFAM Rick Macklem wrote: > > > > > > On Fri, Apr 4, 2025 at 6:27=E2=80=AFPM Shawn Webb wrote: > > > > > > > > On Sat, Apr 05, 2025 at 01:04:25AM +0000, Shawn Webb wrote: > > > > > On Fri, Apr 04, 2025 at 05:40:21PM -0700, Rick Macklem wrote: > > > > > > On Fri, Apr 4, 2025 at 10:50=E2=80=AFAM Shawn Webb wrote: > > > > > > > > > > > > > > On Thu, Apr 03, 2025 at 06:12:59PM -0700, Rick Macklem wrote: > > > > > > > > On Thu, Apr 3, 2025 at 4:52=E2=80=AFPM Shawn Webb wrote: > > > > > > > > > > > > > > > > > > On Wed, Apr 02, 2025 at 01:51:26PM -0700, Rick Macklem wr= ote: > > > > > > > > > > The commit 2ec2ba7e232d just hit main. I do not think = it will > > > > > > > > > > cause problems, but it is fairly large. > > > > > > > > > > > > > > > > > > > > Man page updates will be done as separate commits. > > > > > > > > > > > > > > > > > > > > Hopefully this will not cause grief, rick > > > > > > > > > > > > > > > > > > Hey Rick, > > > > > > > > > > > > > > > > > > The patch review test plan mentions a patch to ZFS itself= to support > > > > > > > > > named attributes. Is that patch available somewhere? > > > > > > > > The ZFS patch is currently in phabricator as D49654. > > > > > > > > Feel free to review it. > > > > > > > > > > > > > > > > It can also be found at: > > > > > > > > https://people.freebsd.org/~rmacklem/zfs-xattr.patch > > > > > > > > (this is a smaller diff which can be applied to an up-to-da= te main src > > > > > > > > tree easily) > > > > > > > > > > > > > > Hey Rick, > > > > > > > > > > > > > > I applied that zfs patch, but trying pathconf(2) on a file on= a ZFS > > > > > > > dataset with xattr=3Don (which seems to be the default) retur= ns 0. Am I > > > > > > > doing something wrong? > > > > > > > > > > > > > > =3D=3D=3D=3D BEGIN LOG =3D=3D=3D=3D > > > > > > > hbsd-current-01[shawn]:/home/shawn/tmp $ ./xattrtest xattrtes= t > > > > > > > xattrtest: Named attributes not enabled: No error: 0 > > > > > > > hbsd-current-01[shawn]:/home/shawn/tmp (1) $ zfs list /usr/ho= me/shawn > > > > > > > NAME USED AVAIL REFER MOUNTPOINT > > > > > > > rpool/usr/home 10.4G 71.4G 9.85G /usr/home > > > > > > > hbsd-current-01[shawn]:/home/shawn/tmp $ zfs get xattr rpool/= usr/home > > > > > > > NAME PROPERTY VALUE SOURCE > > > > > > > rpool/usr/home xattr on default > > > > > > > =3D=3D=3D=3D END LOG =3D=3D=3D=3D > > > > > > > > > > > > > > That xattrtest application is yours from: > > > > > > > https://people.freebsd.org/~rmacklem/xattrtest.c > > > > > > No idea. It works for me. You used up-to-date kernel sources? > > > > > > (Check that VIRF_NAMEDATTR is defined in sys/sys/vnode.h.) > > > > > > Oh, and one more thing to check. zfs_xattr_compat needs to be n= on-zero. > > > > > > (It's found in sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vn= ops_os.c. > > > > > > It's initialized to 1 and I don't see anything that sets it to = 0?) > > > > > > > > > > It is indeed set to 1. > > > > > > > > > > > > > > > > > The only thing I can think if is, if you changed xattr to on, y= ou need to > > > > > > reboot (or at least remount) to get it to take effect. > > > > > > (Maybe try setting it to "dir" and then reboot/remount. Maybe t= here is > > > > > > a difference between "on" and "dir"?) > > > > > > > > > > Yeah, tried rebooting and still no go. Note that xattr defaults t= o > > > > > "on" in FreeBSD by default. My src tree is synced up to FreeBSD c= ommit > > > > > 7e70d94acd68b3ac6b45f49d4ab7a0f7867c3ea7. I brought in the ZFS pa= tch > > > > > you linked to. > > > > > > > > > > > > > > > > > Or, did you build zfs.ko some other way than as part of a kerne= l build? > > > > > > (It needs the patched .h files in the kernel sources, not somet= hing in > > > > > > /usr/include/sys > > > > > > that has not yet been updated.) > > > > > > All the ZFS changes are #ifdef'd, since OpenZFS requires the so= urces > > > > > > build for older kernels. (Basically #ifdef'd on that VIRF_NAMED= ATTR mentioned > > > > > > above.) > > > > > > > > > > Perhaps I need to do a clean build. I'll try that and report back= . > > > > > > > > > > > > > > > > > It does remind me that I need to try a build of zfs.ko by doing= a "make" in > > > > > > the module directory. > > > > > > > > > > > > You can try the attached trivial patch and see if it spits out = "pathconf ret=3D1" > > > > > > on the console. > > > > > > > > > > I'll try that after a clean rebuild of the kernel. > > > > > > > > Clean rebuild didn't resolve it. However, I made some progress. > > > > > > > > I created a dataset specifically for this since I can't really unmo= unt > > > > my /usr/home dataset, so my example down below is a bit different t= han > > > > the previous example I gave. > > > > > > > > The xattr property is set to "on" for the dataset. However, it's no= t > > > > mounted with the xattr property. In order to get it to work, I had = to > > > > run the following commands: > > > > > > > > =3D=3D=3D=3D BEGIN LOG =3D=3D=3D=3D > > > > $ sudo zfs umount rpool/scratch/xattr > > > > $ sudo mount -t zfs -o xattr rpool/scratch/xattr /scratch/xattr > > > > $ zfs get xattr rpool/scratch/xattr > > > > NAME PROPERTY VALUE SOURCE > > > > rpool/scratch/xattr xattr on local > > > > $ mount | grep xattr > > > > rpool/scratch/xattr on /scratch/xattr (zfs, local, noatime, nfsv4ac= ls, named attributes) > > > > $ mount | grep named > > > > rpool/scratch/xattr on /scratch/xattr (zfs, local, noatime, nfsv4ac= ls, named attributes) > > > > =3D=3D=3D=3D END LOG =3D=3D=3D=3D > > > > > > > > So it looks like FreeBSD does not honor the xattr zfs property, > > > > otherwise you would see a whole bunch of datasets mounted with the > > > > "named attributes" flag in that last `mount | grep` command. > > > I've looked at this a little more... > > > There is a function xattr_changed_cb() that updates the xattr propert= y > > > information. > > > It gets called when "zfs set xattr=3DXX " is done or whe= n > > > the mount option "xattr" is set. > > > > > > The question seems to be "Why was the stuff not correctly set for you= r file > > > systems, although they show xattr=3Don?" > > This is indeed what I was inferring. xattr has been set to "on" since > the pool's creation as far as I can tell. Until experimenting with > your patch, I didn't really even know the xattr property even existed. I was able to reproduce this with a fresh zpool. Although it reported "xattr on", that is not really accurate. I stuck a printf() in here (line#853-861 of sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vfsops.) /* should either have both of these objects or none */ error =3D zap_lookup(os, MASTER_NODE_OBJ, ZFS_SA_ATTRS, 8, 1, &sa_obj); if (error !=3D 0) return (error); error =3D zfs_get_zplprop(os, ZFS_PROP_XATTR, &val); --> The printf here shows that error =3D=3D ENOENT. if (error =3D=3D 0 && val =3D=3D ZFS_XATTR_SA) zfsvfs->z_xattr_sa =3D B_TRUE; The printf() of error showed ENOENT. So, "xattr" actually does not exist. "zfs get xattr " calls it "on" but that's not accurate. As root, I did: # zfs set xattr=3Ddir - reboot This makes it work, although the above call still returns ENOENT. It looks to me like zfsvfs_init() gets called from zfsvfs_create() right at the beginning of zfs_domount(). Later in zfs_domount() it calls zfsvfs_setup()->zfs_register_callbacks(), which now finds the property (because of the "zfs set xattr=3Ddir ") and registers it via dsl_prop_register(). I don't know if the above is correct? Personally, I would prefer to see "zfs get xattr " reply "not = set" instead of "on". rick Setting the property makes it work, but only after rebooting (a umount/mount would probably have the same effect, I think?). > > > > Maybe I'll try and ask somewhere there are ZFS wizards or look in som= e > > > OpenZFS commit logs. > > > > > > Have your ZFS file systems that do not have "named attribute" set bee= n > > > around for quite a while? (I'm thinking that they might have been con= figured > > > differently when they were created and never changed.) > > > > > > It does look like the commands (done as root) should do the same thin= g > > > as your umount/mount did. > > > # zfs set xattr=3Doff > > > # zfs set xattr=3Ddir > > Oh, and followed by a reboot or umount/mount without the xattr mount op= tion. > > The ZFS pool in the VM I'm testing was created in 2020. I would have > thought that the datasets would be mounted with "named attribute" > support by default since the xattr attribute is set to "on" for every > single dataset. A reboot does not cause the datasets to be mounted > with "named attribute" support. I had to unmount the dataset manually, > then run that `mount -t zfs -o xattr ...` command manually. > > I suspect that the dataset automounting code paths, as performed at > boot time, might need to be updated. I have zero experience with ZFS > code, so my suspicion could be completely incorrect. > > From a user's perspective, it seems that the xattr property is ignored > when ZFS automounts a dataset on FreeBSD. That behavior is what is > causing my suspicion above. > > Thanks, > > -- > Shawn Webb > Cofounder / Security Engineer > HardenedBSD > > Signal Username: shawn_webb.74 > 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 Apr 5 23:43:48 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 4ZVX9j1s9Hz5sXJV for ; Sat, 05 Apr 2025 23:43:53 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (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 4ZVX9h1gl2z3n27 for ; Sat, 05 Apr 2025 23:43:52 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=hardenedbsd.org header.s=google header.b=e4SxEDRU; dmarc=none; spf=pass (mx1.freebsd.org: domain of shawn.webb@hardenedbsd.org designates 2607:f8b0:4864:20::d2d as permitted sender) smtp.mailfrom=shawn.webb@hardenedbsd.org Received: by mail-io1-xd2d.google.com with SMTP id ca18e2360f4ac-86135d11760so32375039f.2 for ; Sat, 05 Apr 2025 16:43:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd.org; s=google; t=1743896631; x=1744501431; 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=AesN6FBFAsCFgL/LKX0IrvdG8jJ0XRkxWMEFFqGHMEY=; b=e4SxEDRUR0Jzk+wOFBijsyTfVtstt3tClZto+NmjPOTWAzrKEQjGEalM4QwLK060ao d691N5z9CHtbbRbkOTriObdfHCrEeDTdMqHsyCsUPfpncgIIT4PgQOKYgyW/bWENv3of u5gZU6sbicdD/EZcfWruQLVpAK5M8ZmuDZHY3n/UxSO7+Ooyjr9gXXJlRW7iqsddH+RZ amuBigRDi8TTtL+QjeDuKHsoN/bar5CzTBhsTLT66psIWBH0W6HHNzgjw3w4wBt0BBGZ lzkVpw257BZFaqWS45UQu7ZA32X+vLUNnEqvBKyDJAcCWDuQzdYp2mm9aMt6ZUI/kjTT FafQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743896631; x=1744501431; 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=AesN6FBFAsCFgL/LKX0IrvdG8jJ0XRkxWMEFFqGHMEY=; b=SA4M665A3anbWxQhA2eCr7ww4LCunXSGcVALBVDCPHYvW87XRxnw02rZ5P2fgWyukF mJUi2C89m7KIwmHmA/0+Ng9HbtgU2Dt3XpCnrBo95SpoGGsfoFA9wQtuXHjzD91eyAIQ 9uRY50H2bsqbbmg6chF7aCG6pxzjr81hVtQ10Ai0PKLIMlSKkeJuSv4VqriV0V304l38 y8J5cITov6rO7O4T265/qSe0WLULzOsIc3Ov5upRZpWMKv3ySz8FNTbGDXDx1bMwksV6 dsZLsYrYRntRqIeETIvuRrgTx0hSfumJ7xENO7+ae2pNxPAzqmHIWSFQSzgqb/ewPDTh PkVA== X-Gm-Message-State: AOJu0YwAchcLFwA+Ka0BXOVQYowNW+o0Ut3lm8fOyHBLshulXnOAse1v BglxCGAi1NXtYVS3qR7e9B1SFtFC8/eHR/qPab1NjnY2DNltKKUQr0FnMTNwQGI= X-Gm-Gg: ASbGnctsNfOSLTpq6U1yOHGonAcvTJJId7UUR8pRIRIx2C6g1Sunx2Bd43uRQRTukKm KbF+NLmJMI6qhw6fYztXLCVvboH2ZTqhQfL8N+nyQdGr/zoZZ3VXJJdnHeyOT/66829sVx6Po7q pGxNsBXEs6dljzRA46gFnjAdkk1qVeuFEfjHnfWzO8OzJWpYw9zCSguQLCP2CBytn45miHlvf1E cn6964hV5UY4cIznmmUxPr1xOmdfXjTnstJi9eq0xdza4SiKhhVu94gRwsjR6sHkeGjMcCsTJtJ vXCUaKmt14mhbCh3E0qtOSHs6V4= X-Google-Smtp-Source: AGHT+IFlevVtojPjiyUj/gTQSyy0bcTTqRUQym6C1w2pWj+aawoaYXMgPbo9i8nTjPE892g150It/A== X-Received: by 2002:a05:6602:3785:b0:85b:4362:3403 with SMTP id ca18e2360f4ac-8611c301feamr759621839f.7.1743896630599; Sat, 05 Apr 2025 16:43:50 -0700 (PDT) Received: from mutt-hbsd ([2001:470:4001:1::95]) by smtp.gmail.com with ESMTPSA id ca18e2360f4ac-861112890dfsm122716139f.16.2025.04.05.16.43.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 05 Apr 2025 16:43:49 -0700 (PDT) Date: Sat, 5 Apr 2025 23:43:48 +0000 From: Shawn Webb To: Rick Macklem Cc: FreeBSD CURRENT Subject: Re: Heads Up: commit 2ec2ba7e232d just hit main 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: <2rq3bpvhclcipvgg3mo4gml7ysuzbvt6rfnzkprceumzeaeh4b@casrpprm6mgt> <4beaxy5dpajikvafxpjogcxrpyuwwicng5ln5rxbxlbzp2o2g7@ib7wo5jzlte4> 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="ejepkcclmfbqoplx" Content-Disposition: inline In-Reply-To: X-Spamd-Result: default: False [-4.72 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.62)[-0.624]; MID_RHS_NOT_FQDN(0.50)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; R_DKIM_ALLOW(-0.20)[hardenedbsd.org:s=google]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; RCPT_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[hardenedbsd.org:+]; ARC_NA(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; DMARC_NA(0.00)[hardenedbsd.org]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MIME_TRACE(0.00)[0:+,1:+,2:~]; 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::d2d:from] X-Rspamd-Queue-Id: 4ZVX9h1gl2z3n27 X-Spamd-Bar: ---- --ejepkcclmfbqoplx Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: Heads Up: commit 2ec2ba7e232d just hit main MIME-Version: 1.0 On Sat, Apr 05, 2025 at 04:12:15PM -0700, Rick Macklem wrote: > On Sat, Apr 5, 2025 at 9:12=E2=80=AFAM Shawn Webb wrote: > > > > On Sat, Apr 05, 2025 at 08:52:06AM -0700, Rick Macklem wrote: > > > On Sat, Apr 5, 2025 at 8:50=E2=80=AFAM Rick Macklem wrote: > > > > > > > > On Fri, Apr 4, 2025 at 6:27=E2=80=AFPM Shawn Webb wrote: > > > > > > > > > > On Sat, Apr 05, 2025 at 01:04:25AM +0000, Shawn Webb wrote: > > > > > > On Fri, Apr 04, 2025 at 05:40:21PM -0700, Rick Macklem wrote: > > > > > > > On Fri, Apr 4, 2025 at 10:50=E2=80=AFAM Shawn Webb wrote: > > > > > > > > > > > > > > > > On Thu, Apr 03, 2025 at 06:12:59PM -0700, Rick Macklem wrot= e: > > > > > > > > > On Thu, Apr 3, 2025 at 4:52=E2=80=AFPM Shawn Webb wrote: > > > > > > > > > > > > > > > > > > > > On Wed, Apr 02, 2025 at 01:51:26PM -0700, Rick Macklem = wrote: > > > > > > > > > > > The commit 2ec2ba7e232d just hit main. I do not thin= k it will > > > > > > > > > > > cause problems, but it is fairly large. > > > > > > > > > > > > > > > > > > > > > > Man page updates will be done as separate commits. > > > > > > > > > > > > > > > > > > > > > > Hopefully this will not cause grief, rick > > > > > > > > > > > > > > > > > > > > Hey Rick, > > > > > > > > > > > > > > > > > > > > The patch review test plan mentions a patch to ZFS itse= lf to support > > > > > > > > > > named attributes. Is that patch available somewhere? > > > > > > > > > The ZFS patch is currently in phabricator as D49654. > > > > > > > > > Feel free to review it. > > > > > > > > > > > > > > > > > > It can also be found at: > > > > > > > > > https://people.freebsd.org/~rmacklem/zfs-xattr.patch > > > > > > > > > (this is a smaller diff which can be applied to an up-to-= date main src > > > > > > > > > tree easily) > > > > > > > > > > > > > > > > Hey Rick, > > > > > > > > > > > > > > > > I applied that zfs patch, but trying pathconf(2) on a file = on a ZFS > > > > > > > > dataset with xattr=3Don (which seems to be the default) ret= urns 0. Am I > > > > > > > > doing something wrong? > > > > > > > > > > > > > > > > =3D=3D=3D=3D BEGIN LOG =3D=3D=3D=3D > > > > > > > > hbsd-current-01[shawn]:/home/shawn/tmp $ ./xattrtest xattrt= est > > > > > > > > xattrtest: Named attributes not enabled: No error: 0 > > > > > > > > hbsd-current-01[shawn]:/home/shawn/tmp (1) $ zfs list /usr/= home/shawn > > > > > > > > NAME USED AVAIL REFER MOUNTPOINT > > > > > > > > rpool/usr/home 10.4G 71.4G 9.85G /usr/home > > > > > > > > hbsd-current-01[shawn]:/home/shawn/tmp $ zfs get xattr rpoo= l/usr/home > > > > > > > > NAME PROPERTY VALUE SOURCE > > > > > > > > rpool/usr/home xattr on default > > > > > > > > =3D=3D=3D=3D END LOG =3D=3D=3D=3D > > > > > > > > > > > > > > > > That xattrtest application is yours from: > > > > > > > > https://people.freebsd.org/~rmacklem/xattrtest.c > > > > > > > No idea. It works for me. You used up-to-date kernel sources? > > > > > > > (Check that VIRF_NAMEDATTR is defined in sys/sys/vnode.h.) > > > > > > > Oh, and one more thing to check. zfs_xattr_compat needs to be= non-zero. > > > > > > > (It's found in sys/contrib/openzfs/module/os/freebsd/zfs/zfs_= vnops_os.c. > > > > > > > It's initialized to 1 and I don't see anything that sets it t= o 0?) > > > > > > > > > > > > It is indeed set to 1. > > > > > > > > > > > > > > > > > > > > The only thing I can think if is, if you changed xattr to on,= you need to > > > > > > > reboot (or at least remount) to get it to take effect. > > > > > > > (Maybe try setting it to "dir" and then reboot/remount. Maybe= there is > > > > > > > a difference between "on" and "dir"?) > > > > > > > > > > > > Yeah, tried rebooting and still no go. Note that xattr defaults= to > > > > > > "on" in FreeBSD by default. My src tree is synced up to FreeBSD= commit > > > > > > 7e70d94acd68b3ac6b45f49d4ab7a0f7867c3ea7. I brought in the ZFS = patch > > > > > > you linked to. > > > > > > > > > > > > > > > > > > > > Or, did you build zfs.ko some other way than as part of a ker= nel build? > > > > > > > (It needs the patched .h files in the kernel sources, not som= ething in > > > > > > > /usr/include/sys > > > > > > > that has not yet been updated.) > > > > > > > All the ZFS changes are #ifdef'd, since OpenZFS requires the = sources > > > > > > > build for older kernels. (Basically #ifdef'd on that VIRF_NAM= EDATTR mentioned > > > > > > > above.) > > > > > > > > > > > > Perhaps I need to do a clean build. I'll try that and report ba= ck. > > > > > > > > > > > > > > > > > > > > It does remind me that I need to try a build of zfs.ko by doi= ng a "make" in > > > > > > > the module directory. > > > > > > > > > > > > > > You can try the attached trivial patch and see if it spits ou= t "pathconf ret=3D1" > > > > > > > on the console. > > > > > > > > > > > > I'll try that after a clean rebuild of the kernel. > > > > > > > > > > Clean rebuild didn't resolve it. However, I made some progress. > > > > > > > > > > I created a dataset specifically for this since I can't really un= mount > > > > > my /usr/home dataset, so my example down below is a bit different= than > > > > > the previous example I gave. > > > > > > > > > > The xattr property is set to "on" for the dataset. However, it's = not > > > > > mounted with the xattr property. In order to get it to work, I ha= d to > > > > > run the following commands: > > > > > > > > > > =3D=3D=3D=3D BEGIN LOG =3D=3D=3D=3D > > > > > $ sudo zfs umount rpool/scratch/xattr > > > > > $ sudo mount -t zfs -o xattr rpool/scratch/xattr /scratch/xattr > > > > > $ zfs get xattr rpool/scratch/xattr > > > > > NAME PROPERTY VALUE SOURCE > > > > > rpool/scratch/xattr xattr on local > > > > > $ mount | grep xattr > > > > > rpool/scratch/xattr on /scratch/xattr (zfs, local, noatime, nfsv4= acls, named attributes) > > > > > $ mount | grep named > > > > > rpool/scratch/xattr on /scratch/xattr (zfs, local, noatime, nfsv4= acls, named attributes) > > > > > =3D=3D=3D=3D END LOG =3D=3D=3D=3D > > > > > > > > > > So it looks like FreeBSD does not honor the xattr zfs property, > > > > > otherwise you would see a whole bunch of datasets mounted with the > > > > > "named attributes" flag in that last `mount | grep` command. > > > > I've looked at this a little more... > > > > There is a function xattr_changed_cb() that updates the xattr prope= rty > > > > information. > > > > It gets called when "zfs set xattr=3DXX " is done or w= hen > > > > the mount option "xattr" is set. > > > > > > > > The question seems to be "Why was the stuff not correctly set for y= our file > > > > systems, although they show xattr=3Don?" > > > > This is indeed what I was inferring. xattr has been set to "on" since > > the pool's creation as far as I can tell. Until experimenting with > > your patch, I didn't really even know the xattr property even existed. > I was able to reproduce this with a fresh zpool. > Although it reported "xattr on", that is not really accurate. >=20 > I stuck a printf() in here (line#853-861 of > sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vfsops.) >=20 > /* should either have both of these objects or none */ > error =3D zap_lookup(os, MASTER_NODE_OBJ, ZFS_SA_ATTRS, 8, 1, > &sa_obj); > if (error !=3D 0) > return (error); >=20 > error =3D zfs_get_zplprop(os, ZFS_PROP_XATTR, &val); > --> The printf here shows that error =3D=3D ENOENT. > if (error =3D=3D 0 && val =3D=3D ZFS_XATTR_SA) > zfsvfs->z_xattr_sa =3D B_TRUE; >=20 > The printf() of error showed ENOENT. So, "xattr" actually does not > exist. "zfs get xattr " calls it "on" but that's not accurat= e. >=20 > As root, I did: > # zfs set xattr=3Ddir > - reboot >=20 > This makes it work, although the above call still returns ENOENT. > It looks to me like zfsvfs_init() gets called from zfsvfs_create() > right at the beginning of zfs_domount(). > Later in zfs_domount() it calls zfsvfs_setup()->zfs_register_callbacks(), > which now finds the property (because of the "zfs set xattr=3Ddir ") > and registers it via dsl_prop_register(). >=20 > I don't know if the above is correct? > Personally, I would prefer to see "zfs get xattr " reply "no= t set" > instead of "on". >=20 > rick >=20 >=20 > Setting the property makes it work, but only after rebooting > (a umount/mount would probably have the same effect, I think?). So I wonder why neither an unmount/mount nor a reboot causes `mount | grep "named attribute"` to fail for me. HardenedBSD doesn't have any changes to ZFS that would cause that kind of behavior. I have to unmount, but manually mount with `mount -t zfs -o xattr ...` in order to access the new feature you wrote. Weird. --=20 Shawn Webb Cofounder / Security Engineer HardenedBSD Signal Username: shawn_webb.74 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 --ejepkcclmfbqoplx Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEA6TL67gupaZ9nzhT/y5nonf44foFAmfxwC4ACgkQ/y5nonf4 4frBxw//XpMY0Mm1fYtn/BugeW8qjhMsMelDs8KG6csVaVM1PWGy4iyphmvLV1mY 0owRcDWjjly8gfvsSf3jLAAdltGjY+5e/+SbNKzK4/ZL11S7m41b7nRRLKnlCV68 xenIfFMhqb39oacYmBCqLFM94STXyhoewGU+jeWthph5gKv5Y9s2bC5aaIzQhyAl QRtPpwQEpPHxHuGEVQ2znCgIfcWyX0F9Ncq7+CT8NVN+h8UW19fDA0yuKOA1TVtb o8k/m1sJB6IZsOeINxICVSfZd5ci9B4T1Z778Cf6KXYGSHW7ljxTjiu4f5GgVVgS /hDnj72xLwCDmTVNpblqlc4xC2KLEpugI64Q3c1Mf77Fvtb4rF7IjSgXQKgn/WwV EBixO64ylm08bbf2JhmZacTBG8NccGa2v4Zz8Zjdwt+ABi1IjTIbe8/iZDmrultU YbrC4QggcVYdLV4jbdvkXrEcm6UzKKHrQxs2QfZISDy9xJw/ZKbVwPNndxDS9ot4 VfyvN7948LTwAyLJ9T3PzABKufjqv+7uc1EVdAX0NB5GZIEjquMlZ+Wt2q0anB3L 0AkT15DWj34hhsMa/dIfjbXEi3wwiK4AnhZNNMGCo5mjdBGnaH5uqFPEpuaTyz4j i4+mwUn+aYE35Akg2RYo+FarGOpx8/qYreRvEZoBVLuEKsY83h8= =QmFG -----END PGP SIGNATURE----- --ejepkcclmfbqoplx-- From nobody Sun Apr 6 00:36:07 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 4ZVYLD2ZrLz5sc0d for ; Sun, 06 Apr 2025 00:36:20 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) (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 4ZVYLD0fXxz424d for ; Sun, 06 Apr 2025 00:36:20 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x52f.google.com with SMTP id 4fb4d7f45d1cf-5e677f59438so5001406a12.2 for ; Sat, 05 Apr 2025 17:36:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1743899778; x=1744504578; 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=HC6e48hj5fV4bmVQlUOmYVHjcxyMODazbJ9pLXpCPLk=; b=kgbsK4gDmOrv2ClAxZ/2IkUigHAqj1LvDjVWjnTfrLG9KjMUy7OV2CK4HYIpD0sT9G Ybrbmx/U8nsO4w2QemniTm9s9irIaAczuqjGbqZjUGsWt3NvNEHENEICS0LVVkWn2G8u SVv03sYhmfHsKZ3qimyU6flrTLU4rD8CY4hoamI3x7NnaDC7iLC2q97dJ3J+3AjLjG4c rL/A1d30MeDWesaw/a9a3tkIIBDOLpPBKprmFtsDEsE9ZMuOQ9CCfR6G4A6ZCrj3ej7N p9N8g5dLyopex7SB13/ENY+Fy9V4lb09kJurPFH0265UfyaaqghmjnifWZWHpdeWHAtf LdRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743899778; x=1744504578; 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=HC6e48hj5fV4bmVQlUOmYVHjcxyMODazbJ9pLXpCPLk=; b=itbFhRDiKgGt/XzgC5Zl62d0PWfDzBW5sZlwy9DQXp4xK/734dlqIZcdp/kgesFj1C BKhaUzpVdjsaaaPf/t8ZMgzUbmoMM43T6auBof/8PP2m+H0cDEi1jQNbwBzv57Ikcu4G w7DkVYGy+/qKLtjA8EV0hCL6cLpXRQw9XpyxvAel4AkHiYDRqz3hSMTihkmOvd8y8+1H 0YmLUBMLjD8GR1yZxWQlmBFkOOlUUQ7Q5qsHbnSS2m2etv+/FS7Nc0fuM6ULSDaCDtXZ SeL0Q0lyzrHzYvT/n+nXK57bhWV73odoMZh12GgQxqdiTbmo2bygSRQvHMxXZPqD4WW6 brxg== X-Gm-Message-State: AOJu0YxTvjROmfht/AX8DGRATuQ9KwaTKtibQvQIsYwOaAjR+4b7A84N QUGXtWFiXdSRZGI0WTGRwECSnIXY3Tz1wuUs3rfT0tNLYCXvBz5i+yuawCUBkMWWLxyBt+R3me2 zu891CIJVZldFO+DU7UADQS4qgJgyG2Q= X-Gm-Gg: ASbGncv8NKmj5xIG5PDVB9B9XAoVPJLaDcq+WzMbBB4v3g5tOTJrWdrcsDH8j6Ac1Hp p5/kgAhEQDrkCHCMREX3vA7DJ6HHZr7BMHGv37tM4m3NtMeyslr8xf3bUxjnim2quv2cWLsUrUI IKPrNWVEGDvY6HKXY7vnIE4LMKQ6k4+vCbX6RsHMbqgIdtYQbNfgrVcnUxpOBNsxhJM8k= X-Google-Smtp-Source: AGHT+IFRzbTEcA+gSCv9ZCsIuW23ou7umoSzOuVfQgkviSHUCois82GEC9678YmEx4PCnojwVLnCGS1pdRkov0PjBQk= X-Received: by 2002:a05:6402:3584:b0:5e0:9252:3550 with SMTP id 4fb4d7f45d1cf-5f0b5da540bmr6513218a12.2.1743899778079; Sat, 05 Apr 2025 17:36: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: <2rq3bpvhclcipvgg3mo4gml7ysuzbvt6rfnzkprceumzeaeh4b@casrpprm6mgt> <4beaxy5dpajikvafxpjogcxrpyuwwicng5ln5rxbxlbzp2o2g7@ib7wo5jzlte4> In-Reply-To: From: Rick Macklem Date: Sat, 5 Apr 2025 17:36:07 -0700 X-Gm-Features: ATxdqUHxn6WiVvneDkLPEZ38boXXnnoIEDu3Uf0LhodP8JApjPv3Z_9oT6UD8t4 Message-ID: Subject: Re: Heads Up: commit 2ec2ba7e232d just hit main To: Shawn Webb Cc: FreeBSD CURRENT 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: 4ZVYLD0fXxz424d X-Spamd-Bar: ---- On Sat, Apr 5, 2025 at 4:43=E2=80=AFPM Shawn Webb wrote: > > On Sat, Apr 05, 2025 at 04:12:15PM -0700, Rick Macklem wrote: > > On Sat, Apr 5, 2025 at 9:12=E2=80=AFAM Shawn Webb wrote: > > > > > > On Sat, Apr 05, 2025 at 08:52:06AM -0700, Rick Macklem wrote: > > > > On Sat, Apr 5, 2025 at 8:50=E2=80=AFAM Rick Macklem wrote: > > > > > > > > > > On Fri, Apr 4, 2025 at 6:27=E2=80=AFPM Shawn Webb wrote: > > > > > > > > > > > > On Sat, Apr 05, 2025 at 01:04:25AM +0000, Shawn Webb wrote: > > > > > > > On Fri, Apr 04, 2025 at 05:40:21PM -0700, Rick Macklem wrote: > > > > > > > > On Fri, Apr 4, 2025 at 10:50=E2=80=AFAM Shawn Webb wrote: > > > > > > > > > > > > > > > > > > On Thu, Apr 03, 2025 at 06:12:59PM -0700, Rick Macklem wr= ote: > > > > > > > > > > On Thu, Apr 3, 2025 at 4:52=E2=80=AFPM Shawn Webb wrote: > > > > > > > > > > > > > > > > > > > > > > On Wed, Apr 02, 2025 at 01:51:26PM -0700, Rick Mackle= m wrote: > > > > > > > > > > > > The commit 2ec2ba7e232d just hit main. I do not th= ink it will > > > > > > > > > > > > cause problems, but it is fairly large. > > > > > > > > > > > > > > > > > > > > > > > > Man page updates will be done as separate commits. > > > > > > > > > > > > > > > > > > > > > > > > Hopefully this will not cause grief, rick > > > > > > > > > > > > > > > > > > > > > > Hey Rick, > > > > > > > > > > > > > > > > > > > > > > The patch review test plan mentions a patch to ZFS it= self to support > > > > > > > > > > > named attributes. Is that patch available somewhere? > > > > > > > > > > The ZFS patch is currently in phabricator as D49654. > > > > > > > > > > Feel free to review it. > > > > > > > > > > > > > > > > > > > > It can also be found at: > > > > > > > > > > https://people.freebsd.org/~rmacklem/zfs-xattr.patch > > > > > > > > > > (this is a smaller diff which can be applied to an up-t= o-date main src > > > > > > > > > > tree easily) > > > > > > > > > > > > > > > > > > Hey Rick, > > > > > > > > > > > > > > > > > > I applied that zfs patch, but trying pathconf(2) on a fil= e on a ZFS > > > > > > > > > dataset with xattr=3Don (which seems to be the default) r= eturns 0. Am I > > > > > > > > > doing something wrong? > > > > > > > > > > > > > > > > > > =3D=3D=3D=3D BEGIN LOG =3D=3D=3D=3D > > > > > > > > > hbsd-current-01[shawn]:/home/shawn/tmp $ ./xattrtest xatt= rtest > > > > > > > > > xattrtest: Named attributes not enabled: No error: 0 > > > > > > > > > hbsd-current-01[shawn]:/home/shawn/tmp (1) $ zfs list /us= r/home/shawn > > > > > > > > > NAME USED AVAIL REFER MOUNTPOINT > > > > > > > > > rpool/usr/home 10.4G 71.4G 9.85G /usr/home > > > > > > > > > hbsd-current-01[shawn]:/home/shawn/tmp $ zfs get xattr rp= ool/usr/home > > > > > > > > > NAME PROPERTY VALUE SOURCE > > > > > > > > > rpool/usr/home xattr on default > > > > > > > > > =3D=3D=3D=3D END LOG =3D=3D=3D=3D > > > > > > > > > > > > > > > > > > That xattrtest application is yours from: > > > > > > > > > https://people.freebsd.org/~rmacklem/xattrtest.c > > > > > > > > No idea. It works for me. You used up-to-date kernel source= s? > > > > > > > > (Check that VIRF_NAMEDATTR is defined in sys/sys/vnode.h.) > > > > > > > > Oh, and one more thing to check. zfs_xattr_compat needs to = be non-zero. > > > > > > > > (It's found in sys/contrib/openzfs/module/os/freebsd/zfs/zf= s_vnops_os.c. > > > > > > > > It's initialized to 1 and I don't see anything that sets it= to 0?) > > > > > > > > > > > > > > It is indeed set to 1. > > > > > > > > > > > > > > > > > > > > > > > The only thing I can think if is, if you changed xattr to o= n, you need to > > > > > > > > reboot (or at least remount) to get it to take effect. > > > > > > > > (Maybe try setting it to "dir" and then reboot/remount. May= be there is > > > > > > > > a difference between "on" and "dir"?) > > > > > > > > > > > > > > Yeah, tried rebooting and still no go. Note that xattr defaul= ts to > > > > > > > "on" in FreeBSD by default. My src tree is synced up to FreeB= SD commit > > > > > > > 7e70d94acd68b3ac6b45f49d4ab7a0f7867c3ea7. I brought in the ZF= S patch > > > > > > > you linked to. > > > > > > > > > > > > > > > > > > > > > > > Or, did you build zfs.ko some other way than as part of a k= ernel build? > > > > > > > > (It needs the patched .h files in the kernel sources, not s= omething in > > > > > > > > /usr/include/sys > > > > > > > > that has not yet been updated.) > > > > > > > > All the ZFS changes are #ifdef'd, since OpenZFS requires th= e sources > > > > > > > > build for older kernels. (Basically #ifdef'd on that VIRF_N= AMEDATTR mentioned > > > > > > > > above.) > > > > > > > > > > > > > > Perhaps I need to do a clean build. I'll try that and report = back. > > > > > > > > > > > > > > > > > > > > > > > It does remind me that I need to try a build of zfs.ko by d= oing a "make" in > > > > > > > > the module directory. > > > > > > > > > > > > > > > > You can try the attached trivial patch and see if it spits = out "pathconf ret=3D1" > > > > > > > > on the console. > > > > > > > > > > > > > > I'll try that after a clean rebuild of the kernel. > > > > > > > > > > > > Clean rebuild didn't resolve it. However, I made some progress. > > > > > > > > > > > > I created a dataset specifically for this since I can't really = unmount > > > > > > my /usr/home dataset, so my example down below is a bit differe= nt than > > > > > > the previous example I gave. > > > > > > > > > > > > The xattr property is set to "on" for the dataset. However, it'= s not > > > > > > mounted with the xattr property. In order to get it to work, I = had to > > > > > > run the following commands: > > > > > > > > > > > > =3D=3D=3D=3D BEGIN LOG =3D=3D=3D=3D > > > > > > $ sudo zfs umount rpool/scratch/xattr > > > > > > $ sudo mount -t zfs -o xattr rpool/scratch/xattr /scratch/xattr > > > > > > $ zfs get xattr rpool/scratch/xattr > > > > > > NAME PROPERTY VALUE SOURCE > > > > > > rpool/scratch/xattr xattr on local > > > > > > $ mount | grep xattr > > > > > > rpool/scratch/xattr on /scratch/xattr (zfs, local, noatime, nfs= v4acls, named attributes) > > > > > > $ mount | grep named > > > > > > rpool/scratch/xattr on /scratch/xattr (zfs, local, noatime, nfs= v4acls, named attributes) > > > > > > =3D=3D=3D=3D END LOG =3D=3D=3D=3D > > > > > > > > > > > > So it looks like FreeBSD does not honor the xattr zfs property, > > > > > > otherwise you would see a whole bunch of datasets mounted with = the > > > > > > "named attributes" flag in that last `mount | grep` command. > > > > > I've looked at this a little more... > > > > > There is a function xattr_changed_cb() that updates the xattr pro= perty > > > > > information. > > > > > It gets called when "zfs set xattr=3DXX " is done or= when > > > > > the mount option "xattr" is set. > > > > > > > > > > The question seems to be "Why was the stuff not correctly set for= your file > > > > > systems, although they show xattr=3Don?" > > > > > > This is indeed what I was inferring. xattr has been set to "on" since > > > the pool's creation as far as I can tell. Until experimenting with > > > your patch, I didn't really even know the xattr property even existed= . > > I was able to reproduce this with a fresh zpool. > > Although it reported "xattr on", that is not really accurate. > > > > I stuck a printf() in here (line#853-861 of > > sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vfsops.) > > > > /* should either have both of these objects or none */ > > error =3D zap_lookup(os, MASTER_NODE_OBJ, ZFS_SA_ATTRS, 8, 1, > > &sa_obj); > > if (error !=3D 0) > > return (error); > > > > error =3D zfs_get_zplprop(os, ZFS_PROP_XATTR, &val); > > --> The printf here shows that error =3D=3D ENOENT. > > if (error =3D=3D 0 && val =3D=3D ZFS_XATTR_SA) > > zfsvfs->z_xattr_sa =3D B_TRUE; > > > > The printf() of error showed ENOENT. So, "xattr" actually does not > > exist. "zfs get xattr " calls it "on" but that's not accur= ate. > > > > As root, I did: > > # zfs set xattr=3Ddir > > - reboot > > > > This makes it work, although the above call still returns ENOENT. > > It looks to me like zfsvfs_init() gets called from zfsvfs_create() > > right at the beginning of zfs_domount(). > > Later in zfs_domount() it calls zfsvfs_setup()->zfs_register_callbacks(= ), > > which now finds the property (because of the "zfs set xattr=3Ddir ") > > and registers it via dsl_prop_register(). > > > > I don't know if the above is correct? > > Personally, I would prefer to see "zfs get xattr " reply "= not set" > > instead of "on". > > > > rick > > > > > > Setting the property makes it work, but only after rebooting > > (a umount/mount would probably have the same effect, I think?). > > So I wonder why neither an unmount/mount nor a reboot causes `mount | > grep "named attribute"` to fail for me. HardenedBSD doesn't have any > changes to ZFS that would cause that kind of behavior. I have to > unmount, but manually mount with `mount -t zfs -o xattr ...` in order > to access the new feature you wrote. Weird. So, you have done # zfs set xattr=3Ddir followed by a reboot and it still doesn't work? rick > > -- > Shawn Webb > Cofounder / Security Engineer > HardenedBSD > > Signal Username: shawn_webb.74 > 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 Sun Apr 6 00:45:42 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 4ZVYY70thdz5scW8 for ; Sun, 06 Apr 2025 00:45:47 +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 4ZVYY61pGhz44RS for ; Sun, 06 Apr 2025 00:45:46 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=hardenedbsd.org header.s=google header.b="L/MjaAzI"; 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-3d5e68418b5so27387225ab.2 for ; Sat, 05 Apr 2025 17:45:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd.org; s=google; t=1743900345; x=1744505145; 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=SjYj//ZsGspWp3Qjko/S/5C2N87nLkAjp1wxzc/Ci54=; b=L/MjaAzIDoKnx3xUzYQ4NbgrG+diEzVLEXIvI5mZO88sRtI2FwqoxRBCVFtHZKrHQs 3jA9JT1DbyL2zZ3F7HOdULsTM3BTeZHKFObTolllZ/yzeMLSabs4l56TsubH7DiY7nvu goTV/dgyfm92bB0Cm/ptP8F8LhlcdjMTFz9Yba1HRdGAzVR7QbVxotSuwQq7TgUBXkmP ueg+LeCeHgFx52lqA9ZzaCEuAmfTTdMXQApBvsTzI1EfwHKyiecPTthFn73en+lfZSjG q2wELkONMv3TiD3TfAn4r5+nK9fHFfC3d9yFfVy+aBeS2PxzjemtYd31LOa7Wb/FP2Dr YrEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743900345; x=1744505145; 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=SjYj//ZsGspWp3Qjko/S/5C2N87nLkAjp1wxzc/Ci54=; b=HA0p5rRpuyTJZHz0kPbu7FwvKwt/djKhz1n3FN+sAN8KPsKXh+eNVFlAXlFafoNNjp 54/9AKN49W6ITHvHNN3KZlbyq5lA9GNw0ZhwfuHnX9AQrTIXr43bTunE7Jx1AbsOKUhM pncQ/OmPa57ZUEgWl3T6NXzbXOjDkOJsvHNB6E8IA2PkfoUdhrmpoHkqw+/YdeN6b6xw 3WLbLn0gyCWYCPeqQyJHVvLKX5ZREKOVspnSsby7QT7FDV9TkhsFlf75eDy1GLES9ISG jZ8UNQ6dbJCvcd2auIOEM29dmGgBeslPkW5ZTSs5Ug473/ABuspMoXOHbXrwqRlg/LBY FP6g== X-Gm-Message-State: AOJu0YyV3Sj7D2wqXRjZuEpSRpwnYX0bcVT8yeIrwsYWa3NSd5WiUH9A QFid/WVjahLMUXXEi0+C7Xfvt6NshxtY/nM8uToZmL+pCXzsk7HXS2rOFKlyo3s= X-Gm-Gg: ASbGnctcp7s5ff9flGZhPpduCGbXhiJpG6KjajclM0wSbTm7ViB+OpCVFm+ioeQUtD6 pjrW5A1pBDZGQcN0P1Jlss9hCf6fj2spiA8ceSaDGStTdeRSVLiZWJ77jhyUtNvzGp38iAAMTyj bCp1vzU6BliR9wqImd8JgE5p/iiwnQk4R3BCHOR20LoiM07DuYjZ3sHa8476wi/cP+e6zXr0LS9 RookNCC5CSpqR8YF/389XItRbIlj43wv1uBXtL64Abat1+zSf1Tw0Z1jz4kd2SjHsHbZzUY4omp gEZcVZf43ePc+xL9kCd57uhE32U= X-Google-Smtp-Source: AGHT+IF8bNszaLnTUgxJF0XkjGg5Qu+YAz662Y2f1CcFU3IMHUorjepi4pXu/oAbCNqV3Bw+yyGbqA== X-Received: by 2002:a05:6e02:1647:b0:3cf:fe21:af8 with SMTP id e9e14a558f8ab-3d6ec52ce51mr43688365ab.4.1743900344847; Sat, 05 Apr 2025 17:45:44 -0700 (PDT) Received: from mutt-hbsd ([2001:470:4001:1::95]) by smtp.gmail.com with ESMTPSA id e9e14a558f8ab-3d6de973f87sm16098055ab.64.2025.04.05.17.45.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 05 Apr 2025 17:45:44 -0700 (PDT) Date: Sun, 6 Apr 2025 00:45:42 +0000 From: Shawn Webb To: Rick Macklem Cc: FreeBSD CURRENT Subject: Re: Heads Up: commit 2ec2ba7e232d just hit main 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: <2rq3bpvhclcipvgg3mo4gml7ysuzbvt6rfnzkprceumzeaeh4b@casrpprm6mgt> <4beaxy5dpajikvafxpjogcxrpyuwwicng5ln5rxbxlbzp2o2g7@ib7wo5jzlte4> 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="zpqccct4cm4pmrbf" Content-Disposition: inline In-Reply-To: X-Spamd-Result: default: False [-4.82 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.72)[-0.718]; MID_RHS_NOT_FQDN(0.50)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; R_DKIM_ALLOW(-0.20)[hardenedbsd.org:s=google]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; RCPT_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[hardenedbsd.org:+]; ARC_NA(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; DMARC_NA(0.00)[hardenedbsd.org]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MIME_TRACE(0.00)[0:+,1:+,2:~]; 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: 4ZVYY61pGhz44RS X-Spamd-Bar: ---- --zpqccct4cm4pmrbf Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: Heads Up: commit 2ec2ba7e232d just hit main MIME-Version: 1.0 On Sat, Apr 05, 2025 at 05:36:07PM -0700, Rick Macklem wrote: > On Sat, Apr 5, 2025 at 4:43=E2=80=AFPM Shawn Webb wrote: > > > > On Sat, Apr 05, 2025 at 04:12:15PM -0700, Rick Macklem wrote: > > > On Sat, Apr 5, 2025 at 9:12=E2=80=AFAM Shawn Webb wrote: > > > > > > > > On Sat, Apr 05, 2025 at 08:52:06AM -0700, Rick Macklem wrote: > > > > > On Sat, Apr 5, 2025 at 8:50=E2=80=AFAM Rick Macklem wrote: > > > > > > > > > > > > On Fri, Apr 4, 2025 at 6:27=E2=80=AFPM Shawn Webb wrote: > > > > > > > > > > > > > > On Sat, Apr 05, 2025 at 01:04:25AM +0000, Shawn Webb wrote: > > > > > > > > On Fri, Apr 04, 2025 at 05:40:21PM -0700, Rick Macklem wrot= e: > > > > > > > > > On Fri, Apr 4, 2025 at 10:50=E2=80=AFAM Shawn Webb wrote: > > > > > > > > > > > > > > > > > > > > On Thu, Apr 03, 2025 at 06:12:59PM -0700, Rick Macklem = wrote: > > > > > > > > > > > On Thu, Apr 3, 2025 at 4:52=E2=80=AFPM Shawn Webb wrote: > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Apr 02, 2025 at 01:51:26PM -0700, Rick Mack= lem wrote: > > > > > > > > > > > > > The commit 2ec2ba7e232d just hit main. I do not = think it will > > > > > > > > > > > > > cause problems, but it is fairly large. > > > > > > > > > > > > > > > > > > > > > > > > > > Man page updates will be done as separate commits. > > > > > > > > > > > > > > > > > > > > > > > > > > Hopefully this will not cause grief, rick > > > > > > > > > > > > > > > > > > > > > > > > Hey Rick, > > > > > > > > > > > > > > > > > > > > > > > > The patch review test plan mentions a patch to ZFS = itself to support > > > > > > > > > > > > named attributes. Is that patch available somewhere? > > > > > > > > > > > The ZFS patch is currently in phabricator as D49654. > > > > > > > > > > > Feel free to review it. > > > > > > > > > > > > > > > > > > > > > > It can also be found at: > > > > > > > > > > > https://people.freebsd.org/~rmacklem/zfs-xattr.patch > > > > > > > > > > > (this is a smaller diff which can be applied to an up= -to-date main src > > > > > > > > > > > tree easily) > > > > > > > > > > > > > > > > > > > > Hey Rick, > > > > > > > > > > > > > > > > > > > > I applied that zfs patch, but trying pathconf(2) on a f= ile on a ZFS > > > > > > > > > > dataset with xattr=3Don (which seems to be the default)= returns 0. Am I > > > > > > > > > > doing something wrong? > > > > > > > > > > > > > > > > > > > > =3D=3D=3D=3D BEGIN LOG =3D=3D=3D=3D > > > > > > > > > > hbsd-current-01[shawn]:/home/shawn/tmp $ ./xattrtest xa= ttrtest > > > > > > > > > > xattrtest: Named attributes not enabled: No error: 0 > > > > > > > > > > hbsd-current-01[shawn]:/home/shawn/tmp (1) $ zfs list /= usr/home/shawn > > > > > > > > > > NAME USED AVAIL REFER MOUNTPOINT > > > > > > > > > > rpool/usr/home 10.4G 71.4G 9.85G /usr/home > > > > > > > > > > hbsd-current-01[shawn]:/home/shawn/tmp $ zfs get xattr = rpool/usr/home > > > > > > > > > > NAME PROPERTY VALUE SOURCE > > > > > > > > > > rpool/usr/home xattr on default > > > > > > > > > > =3D=3D=3D=3D END LOG =3D=3D=3D=3D > > > > > > > > > > > > > > > > > > > > That xattrtest application is yours from: > > > > > > > > > > https://people.freebsd.org/~rmacklem/xattrtest.c > > > > > > > > > No idea. It works for me. You used up-to-date kernel sour= ces? > > > > > > > > > (Check that VIRF_NAMEDATTR is defined in sys/sys/vnode.h.) > > > > > > > > > Oh, and one more thing to check. zfs_xattr_compat needs t= o be non-zero. > > > > > > > > > (It's found in sys/contrib/openzfs/module/os/freebsd/zfs/= zfs_vnops_os.c. > > > > > > > > > It's initialized to 1 and I don't see anything that sets = it to 0?) > > > > > > > > > > > > > > > > It is indeed set to 1. > > > > > > > > > > > > > > > > > > > > > > > > > > The only thing I can think if is, if you changed xattr to= on, you need to > > > > > > > > > reboot (or at least remount) to get it to take effect. > > > > > > > > > (Maybe try setting it to "dir" and then reboot/remount. M= aybe there is > > > > > > > > > a difference between "on" and "dir"?) > > > > > > > > > > > > > > > > Yeah, tried rebooting and still no go. Note that xattr defa= ults to > > > > > > > > "on" in FreeBSD by default. My src tree is synced up to Fre= eBSD commit > > > > > > > > 7e70d94acd68b3ac6b45f49d4ab7a0f7867c3ea7. I brought in the = ZFS patch > > > > > > > > you linked to. > > > > > > > > > > > > > > > > > > > > > > > > > > Or, did you build zfs.ko some other way than as part of a= kernel build? > > > > > > > > > (It needs the patched .h files in the kernel sources, not= something in > > > > > > > > > /usr/include/sys > > > > > > > > > that has not yet been updated.) > > > > > > > > > All the ZFS changes are #ifdef'd, since OpenZFS requires = the sources > > > > > > > > > build for older kernels. (Basically #ifdef'd on that VIRF= _NAMEDATTR mentioned > > > > > > > > > above.) > > > > > > > > > > > > > > > > Perhaps I need to do a clean build. I'll try that and repor= t back. > > > > > > > > > > > > > > > > > > > > > > > > > > It does remind me that I need to try a build of zfs.ko by= doing a "make" in > > > > > > > > > the module directory. > > > > > > > > > > > > > > > > > > You can try the attached trivial patch and see if it spit= s out "pathconf ret=3D1" > > > > > > > > > on the console. > > > > > > > > > > > > > > > > I'll try that after a clean rebuild of the kernel. > > > > > > > > > > > > > > Clean rebuild didn't resolve it. However, I made some progres= s. > > > > > > > > > > > > > > I created a dataset specifically for this since I can't reall= y unmount > > > > > > > my /usr/home dataset, so my example down below is a bit diffe= rent than > > > > > > > the previous example I gave. > > > > > > > > > > > > > > The xattr property is set to "on" for the dataset. However, i= t's not > > > > > > > mounted with the xattr property. In order to get it to work, = I had to > > > > > > > run the following commands: > > > > > > > > > > > > > > =3D=3D=3D=3D BEGIN LOG =3D=3D=3D=3D > > > > > > > $ sudo zfs umount rpool/scratch/xattr > > > > > > > $ sudo mount -t zfs -o xattr rpool/scratch/xattr /scratch/xat= tr > > > > > > > $ zfs get xattr rpool/scratch/xattr > > > > > > > NAME PROPERTY VALUE SOURCE > > > > > > > rpool/scratch/xattr xattr on local > > > > > > > $ mount | grep xattr > > > > > > > rpool/scratch/xattr on /scratch/xattr (zfs, local, noatime, n= fsv4acls, named attributes) > > > > > > > $ mount | grep named > > > > > > > rpool/scratch/xattr on /scratch/xattr (zfs, local, noatime, n= fsv4acls, named attributes) > > > > > > > =3D=3D=3D=3D END LOG =3D=3D=3D=3D > > > > > > > > > > > > > > So it looks like FreeBSD does not honor the xattr zfs propert= y, > > > > > > > otherwise you would see a whole bunch of datasets mounted wit= h the > > > > > > > "named attributes" flag in that last `mount | grep` command. > > > > > > I've looked at this a little more... > > > > > > There is a function xattr_changed_cb() that updates the xattr p= roperty > > > > > > information. > > > > > > It gets called when "zfs set xattr=3DXX " is done = or when > > > > > > the mount option "xattr" is set. > > > > > > > > > > > > The question seems to be "Why was the stuff not correctly set f= or your file > > > > > > systems, although they show xattr=3Don?" > > > > > > > > This is indeed what I was inferring. xattr has been set to "on" sin= ce > > > > the pool's creation as far as I can tell. Until experimenting with > > > > your patch, I didn't really even know the xattr property even exist= ed. > > > I was able to reproduce this with a fresh zpool. > > > Although it reported "xattr on", that is not really accurate. > > > > > > I stuck a printf() in here (line#853-861 of > > > sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vfsops.) > > > > > > /* should either have both of these objects or none */ > > > error =3D zap_lookup(os, MASTER_NODE_OBJ, ZFS_SA_ATTRS, 8, 1, > > > &sa_obj); > > > if (error !=3D 0) > > > return (error); > > > > > > error =3D zfs_get_zplprop(os, ZFS_PROP_XATTR, &val); > > > --> The printf here shows that error =3D=3D ENOENT. > > > if (error =3D=3D 0 && val =3D=3D ZFS_XATTR_SA) > > > zfsvfs->z_xattr_sa =3D B_TRUE; > > > > > > The printf() of error showed ENOENT. So, "xattr" actually does not > > > exist. "zfs get xattr " calls it "on" but that's not acc= urate. > > > > > > As root, I did: > > > # zfs set xattr=3Ddir > > > - reboot > > > > > > This makes it work, although the above call still returns ENOENT. > > > It looks to me like zfsvfs_init() gets called from zfsvfs_create() > > > right at the beginning of zfs_domount(). > > > Later in zfs_domount() it calls zfsvfs_setup()->zfs_register_callback= s(), > > > which now finds the property (because of the "zfs set xattr=3Ddir ") > > > and registers it via dsl_prop_register(). > > > > > > I don't know if the above is correct? > > > Personally, I would prefer to see "zfs get xattr " reply= "not set" > > > instead of "on". > > > > > > rick > > > > > > > > > Setting the property makes it work, but only after rebooting > > > (a umount/mount would probably have the same effect, I think?). > > > > So I wonder why neither an unmount/mount nor a reboot causes `mount | > > grep "named attribute"` to fail for me. HardenedBSD doesn't have any > > changes to ZFS that would cause that kind of behavior. I have to > > unmount, but manually mount with `mount -t zfs -o xattr ...` in order > > to access the new feature you wrote. Weird. > So, you have done > # zfs set xattr=3Ddir > followed by a reboot and it still doesn't work? Correct, even a reboot does not work. --=20 Shawn Webb Cofounder / Security Engineer HardenedBSD Signal Username: shawn_webb.74 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 --zpqccct4cm4pmrbf Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEA6TL67gupaZ9nzhT/y5nonf44foFAmfxzq4ACgkQ/y5nonf4 4foMnw/+PFbtPvbjr9hrbcfh/ImD3hwv5Ce/asf5okdXEsd/rdMGqeTKzGnOCGmU 3AA3YrGUlFtda0P76Lj2HhlQ4TRyW1sTus0cvOsvdOGjK22vGG3wdd+kahPNk5qu VkONulI9Zg7fCS+MUXZuVSCEeF87oq1wT0ged0PyM4diuAeMFrl6vAI+zYV9gCQO SgvX30cjOL8sWLPlQcayNyijCt3XV1gRpFE+1nzOabVpVyscSPa91Rp8Ckyn/fnk dGoPbUNVQH4Y3Zj8RH32Ikz5fnfr5VQbmdRonLoO+PAvX5WhQNplB8I8EkWThfIJ FTdeVvLGDdthPNytC5tXNs16h8rUggTZD9+Al87ZNQTugTNwoOrPeS/5Ostm/gfV kW+O9lJza/UvAw+Ecap5E9inYlqkVZY1Mbwb3xC/ZMpOQ5lIE+D8r3pGZmrtTyHN 6Mc3yScIKI/INmnIY9nBF2UUM6HAN/GIZ0RKkVfUOoRN9tRXcdvHw02Up/3U+fQX x6k9xHIMJi+D2CAMU/4pfEJf9UhGs86uHtnx2v/AWZa4dvCtTYwxFvoFJWcfdz+X T8Us2JrIXHZadwv6+ShUh2MEOfnbB7M1GqGnL1SagXgPJJI/Ewfx0RRw9bzfWA0O P75h/HD2Ha41vKpQ3jT9SIRfTtQqq3WMMsb2DeyljANX0QjefQY= =PLiI -----END PGP SIGNATURE----- --zpqccct4cm4pmrbf-- From nobody Sun Apr 6 14:49: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 4ZVwGR50vHz5ryB9; Sun, 06 Apr 2025 14:49:19 +0000 (UTC) (envelope-from madpilot@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 4ZVwGR4TCfz3Xby; Sun, 06 Apr 2025 14:49:19 +0000 (UTC) (envelope-from madpilot@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1743950959; 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=LrqmAPzVDadgoFYi6SapQsLljXViC9tW/53f9eAY22A=; b=xQWvNCT9bk5plpLhC3QLdM2tyPAGrwhX39taSUxz+OklbTPX25SIxa2m2q5x1eFpoODhTG E0UDcEK5d7bPJIg8UC94mUlj1+DWDxIXNVQKH2hrpIE2uNeE6EFMCZDxJ63JrSZi0xt9XY uNN32fzlkebxPU6Z4kZQd7xF57/RLoMhF0jHrehoO4ySmE9yt62K8HpT8a2T8rxSAaGj+7 0x5f7Vwk3p1Jp8DKlmpBnxgRongP1MvAFyNn6GC8PsRqRAHNrNc1ROiqmd2Ck7jsCMMdpI ou1SOR7aA1py5DilkKokd2q+74BVMy/V6GQNgzEMRslgqndiaKL/+6krxFRrNA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1743950959; a=rsa-sha256; cv=none; b=OORqZzMQWsQk9d2NkEePhYLOd1eKKY3z61+NPzoAR66wAijn/7IEAhQzb9CbIfWQ+9N4Bj wGrH9J0zqxwsyQxT7qiqDyFuSIcUIb5MQcNMVo5s6tbWjynRtYfKm/aML7szRM3XbgVeIG haeYp2YCXPaTM7AEA/KBjEdTBdV6vCfBlZN9mZ6a25HjFSxizXlFVFTen6LIuexRvWYxPG ewj4JG/wvwkH+HmEA5QmfHFCJ75YWi390vwZZgUiM6lJy5OzsFgqPJQveDJkOTCk+L7ef2 KIzqy+WdoKBXLklsvRKFGU2fLj5ZvtY+wK6nI31bQNeQtCZbOTwUvE6ViYokCA== 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=1743950959; 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=LrqmAPzVDadgoFYi6SapQsLljXViC9tW/53f9eAY22A=; b=dxbUWpyW1JWDq1YXLnlH2MF7G0YnFcWWnN+ft68i0W1aiLhw8cnF42WSHxKCWicAl2NV3d JJlDwyYxGEXDohK3ON/dqCdfvf8tO+eHSXvRvmbRb2OztCCrpXIUKBDnPVBwV/hamyMy8a sjMZfyGpZSUI4cZtLzSQWXhAuFlXezV/1Cm4/YGL24n0YmtQCUn1uHm50GUzwFmTyH07la sfdQHW4hrbLI91/R918KcN0qNMxPgRNBMavNXRkbinDzcB5gBA9iMFvt/swzwSZFCYndKr X3jP3L8WUdvizfOfuaFuEAI6bGh/QpP44LtsDiIgZ5QYrNIfWJztRmH5/DYTpg== Received: from [IPV6:2a01:e11:2002:4280::13:1] (unknown [IPv6:2a01:e11:2002:4280::13:1]) (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: madpilot/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4ZVwGR1hvWzt2g; Sun, 06 Apr 2025 14:49:19 +0000 (UTC) (envelope-from madpilot@FreeBSD.org) Message-ID: <45b17684-75ef-4953-b59a-3c3b483ba21b@FreeBSD.org> Date: Sun, 6 Apr 2025 16:49:16 +0200 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 To: FreeBSD Current , net@FreeBSD.org Content-Language: en-US, it, en-GB From: Guido Falsi Subject: RFC: Implementation of RFC 7217 [A Method for Generating Semantically Opaque Interface Identifiers, with IPv6 Stateless Address Autoconfiguration (SLAAC)] Autocrypt: addr=madpilot@FreeBSD.org; keydata= xsBNBE+G+l0BCADi/WBQ0aRJfnE7LBPsM0G3m/m3Yx7OPu4iYFvS84xawmRHtCNjWIntsxuX fptkmEo3Rsw816WUrek8dxoUAYdHd+EcpBcnnDzfDH5LW/TZ4gbrFezrHPdRp7wdxi23GN80 qPwHEwXuF0X4Wy5V0OO8B6VT/nA0ADYnBDhXS52HGIJ/GCUjgqJn+phDTdCFLvrSFdmgx4Wl c0W5Z1p5cmDF9l8L/hc959AeyNf7I9dXnjekGM9gVv7UDUYzCifR3U8T0fnfdMmS8NeI9NC+ wuREpRO4lKOkTnj9TtQJRiptlhcHQiAlG1cFqs7EQo57Tqq6cxD1FycZJLuC32bGbgalABEB AAHNIkd1aWRvIEZhbHNpIDxtYWRwaWxvdEBGcmVlQlNELm9yZz7CwHgEEwECACIFAk+G+3MC GwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEBrmhg5Wy9KT2uIIAIrawQ89TnqEhi2C OEQAhx3uqWZuNoS6NyiSgsRCmtSnT2GOgH4Ucbr/I37SkV1B3K6HkoL6lwN8Gjf5KOgLqmTi E1W3RTwS7l8PSvdnjM9i7g351R4mTijtxawB/JcQf/Kge3Yqr1V4g6H+wQXHUStmHThbupuN trzRphvR/e5ekT0FTyVfPmpcbm68i2bwZnKUex/TNIECBykYh8b+SYMLhENf2ayRjCIWS2Ad 7tnTKhMtnS5jtW6qjBy4RoTpQD6oR1xIgkTRlQ49roVCUfdHb+Y/kh+U9G1IcoNy4vkg9IfP dwpSfnP+a8j0AZ1hMnOLZ1fYoQrs+4gVLy8Fs7TOwU0EUxB7QQEQAKFhrDceoPdK/IHDSmoj 6SQYisvM7VdhcleS7E9DoEAVt7yMbf6HbbMVTTY6ckvwTWQssywLBXNVqxgc4WLJjzfUhgef +WE75M3+WFYlOVQLGZY/zEVgma1raYnOHNAOzeHLDmEXjbZP6vGAeDyBbGfQPpE7qGYZ7ube T3XwQO+PklcCrvOPj2ZPcAxGNS2xVU/LzONqCrJqLMJSIcCdsbiSP4G5PnDFHtMokaTY6OEr 8OEQfOAerhcHUa/z7Uu8YtmaqKH+QGkE/WEgaRqSiTnv0JOTD+DxehaqvoKPPZ++2NpCZMHB 2i6A/xifmQwEiIjEXtcueBRzkNUQkxhqZyS13SrhocL9ydtaVPBzZatAEjUDDEJmAMLVFs45 qfyhMiNapHJo2n3MW/E5omqCvEkDdWX/en3P7CK2TemeaDghMsgkNKax/z0wNo5UZCkOPOz0 xpNiUilOVbkuezZZNg65741qee2lfXhQIaZ66yT7hphc/N/z3PIAtLeze4u1VR2EXAuZ2sWA dlKCNTlJMsaU/x70BV11Wd/ypnVzM68dfdQIIAj1iMFAD/lXGlEUmKXg5Ov2VQDlTntQoanC YrAg+8CttPzjrydgLZFq3hrtQmfc0se5yv1WHS69+BsUOG09RvvawUDZxUjW19kyeN9THaNR gow3kSuArUp6zSmJABEBAAHCwF8EGAEIAAkFAlMQe0ECGwwACgkQGuaGDlbL0pMN5wgA4bCk X/qwEVC06ToeR6C2putmSWQMgpDaqrv65Hubo+QGmg2P4ewTYQQ4g6oYWS03qHxqVVWhKz7F jfrV+dH8qbCLfSgIcvdBha7ayGZVrsiuMLKGbw36fcmkZPpSDOfHcP0XH8Z+u9CWj0xUkTxA lZ/7i6gYSUpG2JWNtdmE/X8VVEyXusCLwy0K0BI60A/4dRTIX3C4QKrJ3ZbUXegz70ynjHf+ lQMZ9IZKASoRMuS5FozPQh6abvmwZEPdf5I9riUElzvHrqJ8Bx0t3Pujdoth+yNHpnBxrtO8 LkQdrQ58P0SwcaIX33T2U9pG8bhu5YVR88FQ8OQ0cEsPBpDncg== Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi! I have recently implemented and tested the patch at [1], which implements RFC 7217, about generating IPv6 addresses that are constant through reboots, but do not expose the MAC address of the machine, not being in any way derived by those. I'd like to get comments, testing and review for this patch, with the objective of getting approval to commit it to head once it is streamlined enough. BTW I'd like to thank cognet for his suggestions and help with the patch, in particular his help in finding the correct way to implement the dad_failures counter. And thanks in advance to anyone willing to give feedback! [1] https://reviews.freebsd.org/D49681 -- Guido Falsi From nobody Sun Apr 6 15:39:35 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 4ZVxNW3d2jz5s3Jq; Sun, 06 Apr 2025 15:39:39 +0000 (UTC) (envelope-from bapt@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 4ZVxNW33ZCz3m4R; Sun, 06 Apr 2025 15:39:39 +0000 (UTC) (envelope-from bapt@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1743953979; 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; bh=x+YgB9GD6SnXzuPJ+DKKCQGlttKJ7uUHjy5wNu6hY6A=; b=vp2QRTXcNENKugVAZhKuGEVacfoUr8T6aBupEgDAMBdwHVyv1yy2qrhwJbBtTmn3CJ32pT JGlhVc9ANwSkmzJ0gCoGN25YgsDQK3wBy/jNFvhO86mH4EmGe4bKRMONGehHZG+a+DiFRt e7xKSv2u7bgFgzUlrNlT9M03+7oYKY6ULkNJBz8qa+MQj3iX2SGmwkDFpGWYr8yGPGdDgK xGkoNa97Rd2ZiwTkOeSc0NJFGjOZdaVWdX2EKPiBBpypAtPEk7mCmWh04I3rKbjY+3+KLK UPagLzcF7w9KJVK6flB5VhtpitjnV1YZ6XwL+pTlBAOOvfyXg5w9sqF7C3nevw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1743953979; a=rsa-sha256; cv=none; b=QqTuam7uFil1qhRR1M6Icq0Hn47DQ1EaqyLqQxa8GVBqzBt0ICCyMf3svWsUzKuwfVblG1 uo4/1rRT511un54ZY0rFE6b9WEANVv/bXF5jO1KSqv3UT9tkrSfaaBJgCXhyAi2AKHOzO2 h4U/MVclnrtStRtk6G6bWWMIQQpGeLvbDbgonZ6aeJwEjquZRGlaZ+6U8feuBG5+xLESgB f9YcbaM7KXRYcF1fghIfJ4m/RZEV/49ydZvrlUePJp1cyb5LCfc0KUFLryuL+80jxISUYo lz8YZdaK9DHImrNsiPUwvZpNJ9zVwR4V9Ll99mWDpbMt9VIXsTFkTFWfMPZJjA== 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=1743953979; 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; bh=x+YgB9GD6SnXzuPJ+DKKCQGlttKJ7uUHjy5wNu6hY6A=; b=m77/tOhciSFa+zTMEvrzLzmCiPKv8Cj2hWNiYTPyk5LJxZJtUYOj8JBbSFYB06fnrBhCsq 5+vE2tTeBuPJr9dz3qZNsuyrjkc653NaM5B9f/hOSNcZFMLFPiAiOoMAm+7oztOQMVvph0 v3ys4mUoG1Vgniqf+uY1BxcO5G4ALD+1naUDCi14aHMpNslZZv0bEa1COBGqrsOr6/uvG2 W5QHCVmmiwqzHR7aJ1Tj7cyX+Fh3Mp1M+kaAddkfOXFNA9NvOeQ/IW16pWHLFnAn1yaPSg b/GQuK1YLqI+FH33u6/jkRuCu+dYoZNPUNb5so+L+Nx8Sy3MzhunKJfEqQcpUQ== Received: from b.nours.eu (b.nours.eu [IPv6:2001:41d0:303:5e39::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: bapt) by smtp.freebsd.org (Postfix) with ESMTPSA id 4ZVxNW1nqBzv8j; Sun, 06 Apr 2025 15:39:39 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: from [IPv6:::1] (unknown [IPv6:2a01:e0a:274:cc70:6766:7095:c424:9971]) (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) (No client certificate requested) by b.nours.eu (Postfix) with ESMTPSA id 5C434F7932; Sun, 06 Apr 2025 17:39:35 +0200 (CEST) Date: Sun, 06 Apr 2025 17:39:35 +0200 From: Baptiste Daroussin To: Mark Millard , FreeBSD Current , FreeBSD Mailing List Subject: =?US-ASCII?Q?Re=3A_UPDATE=3A_pkg_2=2E1=2E0_looks_to_be_making_offi?= =?US-ASCII?Q?cial_bulk_builds_of_packages_take_much_longer?= User-Agent: Thunderbird for Android In-Reply-To: References: <8E2FBAD3-EF6F-4D99-A340-21F8FD19AE0F@yahoo.com> 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=utf-8 Content-Transfer-Encoding: quoted-printable Le 5 avril 2025 06:58:12 GMT+02:00, Mark Millard a = =C3=A9crit=C2=A0: >[This is an update of earlier notes, now that I've noticed what >is different for the contexts that not seeing larger time frames >in the Mar-29/Apr-01 bulk build starts of official package builds=2E] > >The context here is the official bulk builds started >2025-Mar-29 (beefy 17 and beefy18) or 2025-Apr-01 =2E > >pkg 1=2E21=2E3 was in use on beefy 19 and beefy20=2E These did not get th= e >significantly longer time frames=2E > >pkg 2=2E1=2E0 was(/is) in use on: >(beefy17 and beefy18 are significantly slower hardware than beefy21 >and beefy22) > >beefy17 main-i386 168:11:08 vs=2E prior maximum 74:19:29 >beefy18 main-amd64 168:11:10+ (so far) vs=2E prior maximum 96:28:10 >(beefy18 still has 9338 Remaining and still has status parallel_build:) > >beefy21 142i386 50:40:16 vs=2E prior maximum 40:22:44 [141i386] >beefy22 142amd64 58:51:19 vs=2E prior maximum 49:37:29 [141amd64] > >Note that beefy17 took around 94 hrs longer, more than doubling the time= =2E > >ampere2 main-arm64 is somewhat over 1/3 of the way along but also looks >to likely have a much longer overall time frame=2E > > >Note that beefy17 and beefy18 had/has: >(has large time changes) > >Host OSVERSION: 1500028 >Jail OSVERSION: 1500035 > >beefy19, beefy20, beefy21, and beefy22 had: >(mix of little vs=2E large time changes) > >Host OSVERSION: 1500035 >Jail OSVERSION: 1402000 > >ampere2's main-arm64 has: >(has large time changes) > >Host OSVERSION: 1500035 >Jail OSVERSION: 1500035 > >So: The new Host 1500035 use is not the cause=2E Nor is Jail 1402000 =2E > >=3D=3D=3D >Mark Millard >marklmi at yahoo=2Ecom > yes this is known and expected, because ofnthe support of provide/requires= in a way the ports tree can use it (pkg add) we added some code which intr= oduce performance penalty, we expect to be able to improve performance agai= n by using those features in the ports tree for real (right now the work is= in poudriere, then the features will be added to the ports tree) bapt From nobody Sun Apr 6 17:53:49 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 4ZW0Mk6Df7z5sFJL for ; Sun, 06 Apr 2025 17:54:10 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-54.consmr.mail.gq1.yahoo.com (sonic316-54.consmr.mail.gq1.yahoo.com [98.137.69.30]) (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 4ZW0Mk55rCz3ByD for ; Sun, 06 Apr 2025 17:54:10 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1743962044; bh=rSKABcAMzudbZ9nTrBEKdol17O8kjYlDYfZyEtxUJPQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=HaZszwhlTXi0r/fgFcUVk89tY3K4ckHb0pAHj9/kAFv6ItYjfmpI4ZDQuJFYUorjpr8cR93cVx97UWtBWCPlj9j9wHZyTQWhnmYXtBblQnJUgSMCc/qfcDEEBVFZJuQ0OzzY9cMKnBsx3IphLTnh8G4x9fv35kWuMp/IKnmd7WwHjLO4koboVb5S6lrRNOG985Js3e/Mk5YAB6kfcZzhvuEI6YVlmr/3qJHh7tk2Z22bRGzX6erkgH+yFjgW5WgMY3lfeIzVDWKo/S/IYDp+yA28xwH+74xyDHqLcZ4ARJY69VyEph0zXzMcba+Ehqf63VTmpvxFUaJyYlw/DXVgHA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1743962044; bh=g5eWcEyaUQ7366KxNkjqCnUK7OoP1P5AoXH1JPpLB9h=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=uR5/bGTRf62JyG+uOCdFaQZWkhV0u67suXNNndczhQ2H6tNfBsIhL3un/8USw7AebgGsj3pgDmuvBQOjMiFyd0pGsN5dWRIpgBjaltCGxqDedVTYv3xWiIF05LSC6cJ44ujTPu6uwfgKQLmgO8tjlfwMclXLOpxSIMvWOalrnK+Cq03p6Go3Z6d7jStJ66w9iWdr/j3snJJGT1JopcOOh0wIyyLi6QpUZytwWwuem+7ccV7fs+qbTiNxBr2oL/Zi7Jn5sLKZ95AapYRYvsmaxVwriETWUXFfraK8rdMo9kWIYTvvHcAHi64uwtkCjDjZnV954egU2UUsz24/ncCpqw== X-YMail-OSG: _0SxqS0VM1lt6BVJRhK0_eGVAw.kJON1lfSA8dbWX2aufRi.jdfUoR0sL83obR9 WOTTk8PeSoe7g8TooaYeoArKUjoL0dtuAfsz4lLyRWmnqQ1BIFGG5UyTipRHwn32VpKXUzBpAer4 QbTEagoJvU6fSQkeOWuDm9V0z2Jo2vma0zihoZxHbOpf0B5FC0G.PgUbuRY_b2rmrL15_rk9_viB KJKSA8Z8MDJNQp4.5YKhekIPpvAb_9.oTJaUqNsmEFw25RX6GH9WovoPN0q6bFvhTSzTjoE2j9iS xvWSTMumG_1XO7CYcDCbLtXUmTLCCRcE.luEbXjtAdfCQbL.i2XtioQcd2BRfLV_AGwVqyi7WH6_ Pe4vPin12VkzojkQQUdrye_LNWspV3x_85fjbn.FfLd70TqLxTFRg4QmKyVBfZ6N7KpxhDSmAtgO E1vVXivBYH0y6lQqt_t.6JAnQDpqhmMz4fxTHTn2TUmyel8TEFoDndy4rDLInoenqhogk6UroULc v3VWKWGd7sH4un2TdAsAtQMt8Gw2ZSGZzsG.kH3aAflTvZXTldVd.Wns_lAefrNtDl9rJF6l9fYQ CygtCGKwKShmXJ.CYWOzQPA8x6fFpuBX5RUClWlGZHaTkbkU4_OypZ_CHmLvbuHqFDGWYiNVlqi6 YK9SCSLpPB7GHGbGrk._DF8MnZYPStnQjP4SM4HKcGRDFGnzz4HdpU0srrSgdHa_uv.f2_V2yZgG WN1HQPXTMSUjAzs9Dg5WdTzNCuPlMu2qvw1nwR8spfiZ.by74q6EbFVC8gved9P70sOSIGbdNU5W wbV5T.lumuu7O5QX1TLv0sNr_0eYjf0R4D0Vtie.wqPd.k.DTHSqGjx6twT9jZ.ZcEeMnTP3499x PUP5EyfkRUDQFo9YaPL8wE78TkIMmeaVw_mz6isg_K4bo6IVpGOBQVBLBS0G0Gh3JPpNhUzdSGNd q9qDR0UeAjL95yBpBFHakZrasQLc67yCL6UwQRnjWYqw3tXTnfKk55GoVgI8wBtlj0tjyLfFZx2a H05v4Mmaa27.fNX.pB9E4cmR_k_id5pKAXIrrdLc358eSpm2kAhBKOkzd8DlgA0gpD9bMmNueYj_ fLa2NEeeYXyb1SCIMzurG6_ZlBwgKmmKzRbgVlA6A.yf4PwvAoRUsOhCqOiYlX4GqyDDWDxyoN0H __MbB5bSnU2HJxmUy1eunY00OvKYJrU7n0Q9wzmNWKfajYNYkHw7sJrLMxhcqzkh4eCheTpp.FB4 clDBJHSBhwderry33gqXWq4sCuXawc9j3aJEI7VJs7JHku9ES2XH1TD6_gFciOBajL7Kr3TG5GUC nMOxegzB7PIFJvtFjZb2E99D7f93NVl8y9G4RhXJwvootT4Ze6U.w88NjfdWfanoQzrlQRjGDXNk NzHcyxTIOovynWSRVzdodxUli6zcVNrMPViVond2J.e_4NyKv7lU5pQZmcAgbzztkmLaK35apC4g CMTNo7N.ldCbyH1x.34Nh_W18sLIqZi.1KEQKSaB.vLvOx7XfVad8u6RT6InMLF2s8T1RUM2v.p6 pCntC6AKsSDqJhPkBsm1mR7DAiAqjliflmNd_uN8BH1BCXXYmbIWJ.am6vwQ3BDHKNUTJw5gCgs8 WHq.vRjGU2LjRdDsI5UjOT57N42DZN6qFwYg20f981jTp7.yW2yRYCiOxAy9TpstJSs5ge1H.ClJ FAR3fBUrzQFQzDvjyRh2QRZQPqL1QPR8AgMLYau.aevPfm6bDfO3gxgLj9oNRSuTME1hSXLm9QtZ LCY.3sOnuSl1kVrWp5C3uTohJX6TgkvfXZ_k_gFwY6CVylOD.Bp1ymSOJSjtd.Gpga6VHkV2XgpP uNcYhou6KfQtcoXrMS7pojcFBbfbcBxrVXI66yvPj5VnvZIA9RZ2_oaS3gqqSEeSY.8fPEMx0h7p _8820YGhs9mflM2kk01NQJEzEs.7O73KQ6N98c.wmMKq9NgEHHfWaecP8E8AVmJi.3u_ETf9qCLM 3lnXAKn8r_PkVVAl6ilmBoHYRgdmfLKqot9ihaT6xNI1s8aL9jHDQIbwzsY9h312qc1xDcN9InGk K6vHqEt4OFcrkjq1xYQxT5DaBoo3TwGhOXCrmXdrKA9wSmq0pKiyc7erNiEDfwki_3SrlvjMZ7bi 31qpOUFoNlMvUdHDAKu9ImaK_eORBQCqC9RbnSV8IxiCqzhURE9T10TQEcmTtpKQ4.jpyYnW2SJJ 6QpH6bdK7CCkv3HMbGC66W3nzHOORsXgRWE.K8r2KMuExttfQHEdGztksAeXvOi1HMSizCnJQSER VJw-- X-Sonic-MF: X-Sonic-ID: 44cb1506-5724-4ba8-949d-566ea887243f Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Sun, 6 Apr 2025 17:54:04 +0000 Received: by hermes--production-gq1-5c477bf655-pmr4h (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 7118208c90ac739641f64070c3bd02d2; Sun, 06 Apr 2025 17:54:00 +0000 (UTC) Content-Type: text/plain; charset=utf-8 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.500.181.1.5\)) Subject: Re: UPDATE: pkg 2.1.0 looks to be making official bulk builds of packages take much longer From: Mark Millard In-Reply-To: Date: Sun, 6 Apr 2025 10:53:49 -0700 Cc: FreeBSD Current , FreeBSD Mailing List Content-Transfer-Encoding: quoted-printable Message-Id: <84FBBAF8-025E-4B9D-9797-51735567A8DB@yahoo.com> References: <8E2FBAD3-EF6F-4D99-A340-21F8FD19AE0F@yahoo.com> To: Baptiste Daroussin X-Mailer: Apple Mail (2.3826.500.181.1.5) 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:36647, ipnet:98.137.64.0/20, country:US] X-Rspamd-Queue-Id: 4ZW0Mk55rCz3ByD X-Spamd-Bar: ---- On Apr 6, 2025, at 08:39, Baptiste Daroussin wrote: > Le 5 avril 2025 06:58:12 GMT+02:00, Mark Millard a = =C3=A9crit : >> [This is an update of earlier notes, now that I've noticed what >> is different for the contexts that not seeing larger time frames >> in the Mar-29/Apr-01 bulk build starts of official package builds.] >>=20 >> The context here is the official bulk builds started >> 2025-Mar-29 (beefy 17 and beefy18) or 2025-Apr-01 . >>=20 >> pkg 1.21.3 was in use on beefy 19 and beefy20. These did not get the >> significantly longer time frames. >>=20 >> pkg 2.1.0 was(/is) in use on: >> (beefy17 and beefy18 are significantly slower hardware than beefy21 >> and beefy22) >>=20 >> beefy17 main-i386 168:11:08 vs. prior maximum 74:19:29 >> beefy18 main-amd64 168:11:10+ (so far) vs. prior maximum 96:28:10 >> (beefy18 still has 9338 Remaining and still has status = parallel_build:) >>=20 >> beefy21 142i386 50:40:16 vs. prior maximum 40:22:44 [141i386] >> beefy22 142amd64 58:51:19 vs. prior maximum 49:37:29 [141amd64] >>=20 >> Note that beefy17 took around 94 hrs longer, more than doubling the = time. >>=20 >> ampere2 main-arm64 is somewhat over 1/3 of the way along but also = looks >> to likely have a much longer overall time frame. >>=20 >>=20 >> Note that beefy17 and beefy18 had/has: >> (has large time changes) >>=20 >> Host OSVERSION: 1500028 >> Jail OSVERSION: 1500035 >>=20 >> beefy19, beefy20, beefy21, and beefy22 had: >> (mix of little vs. large time changes) >>=20 >> Host OSVERSION: 1500035 >> Jail OSVERSION: 1402000 >>=20 >> ampere2's main-arm64 has: >> (has large time changes) >>=20 >> Host OSVERSION: 1500035 >> Jail OSVERSION: 1500035 >>=20 >> So: The new Host 1500035 use is not the cause. Nor is Jail 1402000 . >>=20 >> =3D=3D=3D >> Mark Millard >> marklmi at yahoo.com >>=20 >=20 >=20 > yes this is known and expected, because ofnthe support of = provide/requires in a way the ports tree can use it (pkg add) we added = some code which introduce performance penalty, we expect to be able to = improve performance again by using those features in the ports tree for = real (right now the work is in poudriere, then the features will be = added to the ports tree) Good to know. You might want to send out a HEADS UP style notice for = folks that build their own packages. A lot of these folks do so in order to get security updates quicker as far as I can tell. A known large change = to their build time frames could be important to their planning. It might be appropriate to suggest temporarily manually controlling the version of ports-mgmt/pkg used to be 2.0.6 (or before) for those for = which time to build is the most important in the interim. It looks like ports-mgmt/poudreire* would not need to be controlled = (yet?): It looks like ports-mgmt/poudreire has not been updated since = 2024-08-25 . It looks like ports-mgmt/poudreire-devel has not been updated since = 2025-02-09 . The notes may be of use to some others. For me, the likely implication is to stop updating my ports tree builds except on the fastest amd64 system and fastest aarch64 system and to stop building for armv7 for now. (The fastest aarch64 system does not support AArch32/armv7 and the fastest that does support such takes over 5 times as long compared to fastest aarch64 system.) Going in another direction of questions for folks that do their own bulk builds of packages: Context for the next paragraph: Already "using those features in the ports tree for real" for someone doing their own package builds: Will bulk -c builds (for example) always suffer the longer build times by not having prior information for reference (because of the -c)? What sorts of activities would destroy the information for the next build attempt if that is an issue, making the next build take the new, much-longer overall build time? For example, updating the poudriere jail's world? Context for the next paragraph: Just before "using those features in the ports tree for real" for someone doing their own package builds: How will one get to the point of "using those features in the ports tree for real"? How will a self-builder of packages get to the point of being able to test the build times in the "for real" context as well? > bapt Just for reference for official main-arm64-default bulk -c -a (from scratch) builds: p25bf3a3260c7_s680d34896c3 queued 36447 and has built 15523 and has 19479 remaining, 134:23:16 so far (will have built up to 15523+19479 =3D=3D 35002 when done, if it = finishes) So: 12 to 13 days (around 300 hrs) as an estimate. The prior longest main-arm64-default official build that completed: p02dd5021d6f9_s717adecbbb5 queued 36466 and had built 34853 and had 0 remaining, 163:20:35 So: 6.8 days or so. Overall: very roughly doubling the overall time when the "for real" context does not apply. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sun Apr 6 20:27: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 4ZW3mV5gFQz5sRsx for ; Sun, 06 Apr 2025 20:27:22 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-25.consmr.mail.gq1.yahoo.com (sonic303-25.consmr.mail.gq1.yahoo.com [98.137.64.206]) (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 4ZW3mV2xdzz3jsn for ; Sun, 06 Apr 2025 20:27:22 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=gLXLIBQb; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1743971235; bh=+XLIW2fpCwnwESHdNMkrtP3s559uFe/Cu3c8k37KxZo=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=gLXLIBQb7Qmg2XpKhSsU5kZQxO7Fji7LgZMEJux5zLyXXozFnThnIE1Brhfetbpu4eH/jzlEs/qnLaH/egpmaOKUmOBcWAi096rJUR+pzgaC12qoBkGoqZu9V3bPgzP4af1PMrTZQmkRQRBMBHXqrCev3h2wIL+CuLEWLiWl+7nLFAOv7BeoQKCVwNtNMyf6TRGfCzMpaqwa6gx2SORwpVV6RzhqO3MiI7VBVJuEKok4Ua2L9usXIKI3+U29HmxJ/IHKimINlluHoQtYl8bG+acqZ3EkWazvOApd9o5Jpp7hu9y2WyaLZE0rGRrQdyRMxprVbU3ER4CULSfnhqCzuw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1743971235; bh=Iqoy8UvZMSvhdnWE8KqoL+vjk1ALd9WMd6UfJBDHZGa=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=kt12jUlezQppLS/wfMxK9I1tlmsYv/E6xyzlQzPthrDSm/1KyYIG57ZpDRToh8B0gRJIMYPqZBY7hZ+9MNUkjTAEHCorFE8OgOqOZvxCDQBiPZ6FlVyH/4L5ofB5GBu5TjiSb4IFG5bpTW88VOAc1iknI35vmmv84LzwB1Fa/uT9hk54mKGNDuzXTL4j73LeQHwqXcAm8Rpt/OfRvSD1eRGonnZ5ZB9AtbqqKc2bg3s63ZnfmZNBLUOR0MaZHhbONIbCFbIgC1aKNFJqL+rx5PW4vuy3BYz5T7hX6v/uvi5xKhd9Sjf4BRkztx6KLVXMNeajXLjbd3QnhhQSZwtMBA== X-YMail-OSG: Gs0mdXoVM1mOSPII2jQTzghDVn1sIgGY2hvsSBE7E0rC2jgP6I1QFy7vWKJOKoS .X15DOFTdsWwYKdi7Uld4sYx3TCX5gsYqpu30_hG97QPwVl2vCnU.WHFLi6DiAT49tsg9eewZg3k xGnbe.yVztcpzntwKvIOUsuP9cBCDnq44MMC20ohfgyrg5w6Rq4TrAfK_3wIebt_d38lP3_1TaWB ONeC4F3tLuheGVZzMdlmVjcXW_B8LFaGaNdV8o2Z5p6ibGjLdQl8DjBEmk0yq8dq6v5qIzv.Hl0K owPNGSkoyS52D6hzTPg2ZEb5i81eoz_dECxlVbxqLPikvNEL4v0MCNMVUu4MNrVX4daLz0oh5ueK FLh8SS0U5SVVUFLhsz25z3pbJweZ9lSKADTwyXItjbKpGEQYlITHwC9JWIrwXMjDfWdKepi5dupN C4ZnG5oIq8BJaCAIPKJl91tVcXXTi7zFGjZdhmv6s6zCWI0DpCqzH4c1V9Pj4hJ.40VAxV1KIuSR ss2oxBfaDagLcC7pDkRbZsvoHhHFnPHoUVNAPLnMB4ujz5e8TGp7Dag2b95LdjsL5DjvW104xFJ. LZ.4s2TWx_YxyJYGcSPc4eJxD.ckzgBBiaIQpblBQY0DmcJ7X1VDIsCxv_kMXOqAOZu_PqlGbyQw wMuTn6mppDrwaTvqdAfVG.zg0WG65ZN.QQHXuWPQYSRRnGYKgCJidQv4BSdjaVL5ALAebcKelWaa 9tBaB.ba3uHrD.eWDmw1rg_46TsHkvDPyiEl0UBEh3v0yHIf4YX.QhFOSAhVY9bHbNf0EAeFPdx_ Q5DjjLwJt3XwqQyuowi2cAzRkrPLd.nf46D1OOWhOw5if6EIHBgU6osBCM7oUBbXRC3_QIA0rsvc G1Fl1YJSQPU1Mv.h0g3PCAcwI_o7TZqdq08P8tD0AWw4nVSqaBqtUzHXRO7.FP5VOKc6GqLO_qXe Is1pHbqxrMJ9WXr3SnswvuYiD4tGPJvPOucgcg9JgFCPtnM9jomYuPmDtq0WdYc.K82nYKpdxBDH RHSU0jJCBTx7KLpTShj6mILudeA_cyWH0j47OY7Dyem7M8lp2a4JcvNzsjklPmPlheIoPid4UXl4 3oUoUrQO5Wvp_NL9_enIr6XbkSHA1vrP5m8fDHv.T3Y1PI2UUonplLYVWvZLU7ucIJQf2PVJYDKQ ZrXTIYtoSzyXkpcyT_QZma_AWGqAtUnIqRNO2XIGZz5DydMTrROKjpwUdcRwT6dSAx4H5kQ6QK0h _Fb_J7hlGrnzKq9MfXT0QvofERialtKc3dfanqVtWsTBKOU6mhyfMnfpF7rNkuHWWEUDHNfugZC2 jdEr6TMMi.KUMX8M5.cej6b2FzAdtJayILf7tq4FwOCjEgNMQGXEsr1UYDkh2bIVUF5flqCujkgu 3l4lE2Ua296GoB4GkjI5FezjKFkR8qnbts3_MfEUKM5DgpTG8DdRrApOD7jOr9evQWGFBumU.u5c CLlkDKpBDkux8Ox_UTUnXINEiBwAtYhqkCszrrL74baxeKIe7SjuEu9T6FTnJs9zFEXcQLMGeAWb RdQLa3BxJu6gbEKMAUbZbhH0MVq_C64tWEOotOyIWUGj1bwwcHFIDdvgvtaz0dttG7KguqJzZQOP UzwgVd0OJT4oeJaKh.VjcJaXy82TmloHUgvMmaa7bph6jW3TF_nmxyGD1ZXQN5Tj2sTNBYpOdiXZ gWcphZMV.cqE79zD7Vh1D85ODnNfjNDCvmxgvdO8n3sm8NRUNX4xBrUA9iv9sa_HoJmZFIocOuZb e0wP9cVVh3ZhnWZ.bL09lx3vxZKhMq3xnmgtHPQynKrLgKYzn35ZsfJOp9gEGz5GwyEnCP6cQ3V. Gdk26x8wTSQAhReTaLgr10iel7ORoVyNyBcfml3YfBQ1oBoAWKyRmxlVQbZGZQwFfUewnJAhQQzF RdagoI2M0qy3cUAmezOfUA7LvM4ASR6t7wO79HIEHRZ9tuwjq74MTnJs_OUSktKjqJ67HQKSSniz nmRvWzNhSzp8GROcuPL8KjWGfq66IJNOV1jFQChuPauTECudgDPozoPTGBufPLEHgV8yb_q7veGk uk.rd8arGyKaY9hDo5BYBsqFngHzTWF5c0YHM_KGnVREbEte3LCO2Ckzt8ugNeHnDJvrXVHrsILj 9knw3LrUgb7fnIVkGrcPlo_3f7jG5AoQgtLWJBybt7wEiruRMBI_hIY.ypxec0ihYwMsDCoTy.SP hDChP1vsMnrW9WiA._HIBqYXp5CUBYMpm3FCtG9u_TutpkTGh4gJ2kiebHW0VUfXchfiLlm.hxEh 3 X-Sonic-MF: X-Sonic-ID: ac6dba3b-721b-42a9-80a0-e77ee9b3ffd7 Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Sun, 6 Apr 2025 20:27:15 +0000 Received: by hermes--production-gq1-5c477bf655-s8xr7 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 5c87b60c86fc767433d06885e9e208df; Sun, 06 Apr 2025 20:27:11 +0000 (UTC) Content-Type: text/plain; charset=utf-8 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.500.181.1.5\)) Subject: Re: UPDATE: pkg 2.1.0 looks to be making official bulk builds of packages take much longer From: Mark Millard In-Reply-To: <84FBBAF8-025E-4B9D-9797-51735567A8DB@yahoo.com> Date: Sun, 6 Apr 2025 13:27:09 -0700 Cc: FreeBSD Current , FreeBSD Mailing List Content-Transfer-Encoding: quoted-printable Message-Id: References: <8E2FBAD3-EF6F-4D99-A340-21F8FD19AE0F@yahoo.com> <84FBBAF8-025E-4B9D-9797-51735567A8DB@yahoo.com> To: Baptiste Daroussin X-Mailer: Apple Mail (2.3826.500.181.1.5) X-Spamd-Result: default: False [-4.49 / 15.00]; RBL_SENDERSCORE_REPUT_9(-1.00)[98.137.64.206:from]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.995]; NEURAL_HAM_MEDIUM(-0.99)[-0.994]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; DKIM_TRACE(0.00)[yahoo.com:+]; ARC_NA(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_THREE(0.00)[3]; FROM_HAS_DN(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.206:from]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.206:from] X-Rspamd-Queue-Id: 4ZW3mV2xdzz3jsn X-Spamd-Bar: ---- [I thought of another question.] On Apr 6, 2025, at 10:53, Mark Millard wrote: > On Apr 6, 2025, at 08:39, Baptiste Daroussin wrote: >=20 >> Le 5 avril 2025 06:58:12 GMT+02:00, Mark Millard = a =C3=A9crit : >>> [This is an update of earlier notes, now that I've noticed what >>> is different for the contexts that not seeing larger time frames >>> in the Mar-29/Apr-01 bulk build starts of official package builds.] >>>=20 >>> The context here is the official bulk builds started >>> 2025-Mar-29 (beefy 17 and beefy18) or 2025-Apr-01 . >>>=20 >>> pkg 1.21.3 was in use on beefy 19 and beefy20. These did not get the >>> significantly longer time frames. >>>=20 >>> pkg 2.1.0 was(/is) in use on: >>> (beefy17 and beefy18 are significantly slower hardware than beefy21 >>> and beefy22) >>>=20 >>> beefy17 main-i386 168:11:08 vs. prior maximum 74:19:29 >>> beefy18 main-amd64 168:11:10+ (so far) vs. prior maximum 96:28:10 >>> (beefy18 still has 9338 Remaining and still has status = parallel_build:) >>>=20 >>> beefy21 142i386 50:40:16 vs. prior maximum 40:22:44 [141i386] >>> beefy22 142amd64 58:51:19 vs. prior maximum 49:37:29 [141amd64] >>>=20 >>> Note that beefy17 took around 94 hrs longer, more than doubling the = time. >>>=20 >>> ampere2 main-arm64 is somewhat over 1/3 of the way along but also = looks >>> to likely have a much longer overall time frame. >>>=20 >>>=20 >>> Note that beefy17 and beefy18 had/has: >>> (has large time changes) >>>=20 >>> Host OSVERSION: 1500028 >>> Jail OSVERSION: 1500035 >>>=20 >>> beefy19, beefy20, beefy21, and beefy22 had: >>> (mix of little vs. large time changes) >>>=20 >>> Host OSVERSION: 1500035 >>> Jail OSVERSION: 1402000 >>>=20 >>> ampere2's main-arm64 has: >>> (has large time changes) >>>=20 >>> Host OSVERSION: 1500035 >>> Jail OSVERSION: 1500035 >>>=20 >>> So: The new Host 1500035 use is not the cause. Nor is Jail 1402000 . >>>=20 >>> =3D=3D=3D >>> Mark Millard >>> marklmi at yahoo.com >>>=20 >>=20 >>=20 >> yes this is known and expected, because ofnthe support of = provide/requires in a way the ports tree can use it (pkg add) we added = some code which introduce performance penalty, we expect to be able to = improve performance again by using those features in the ports tree for = real (right now the work is in poudriere, then the features will be = added to the ports tree) >=20 > Good to know. You might want to send out a HEADS UP style notice for = folks > that build their own packages. A lot of these folks do so in order to > get security updates quicker as far as I can tell. A known large = change to > their build time frames could be important to their planning. >=20 > It might be appropriate to suggest temporarily manually controlling = the > version of ports-mgmt/pkg used to be 2.0.6 (or before) for those for = which > time to build is the most important in the interim. >=20 > It looks like ports-mgmt/poudreire* would not need to be controlled = (yet?): >=20 > It looks like ports-mgmt/poudreire has not been updated since = 2024-08-25 . > It looks like ports-mgmt/poudreire-devel has not been updated since = 2025-02-09 . >=20 >=20 > The notes may be of use to some others. For me, the likely implication > is to stop updating my ports tree builds except on the fastest amd64 > system and fastest aarch64 system and to stop building for armv7 for > now. (The fastest aarch64 system does not support AArch32/armv7 > and the fastest that does support such takes over 5 times as long > compared to fastest aarch64 system.) >=20 >=20 > Going in another direction of questions for folks that do their own > bulk builds of packages: >=20 >=20 > Context for the next paragraph: Already "using those features in the > ports tree for real" for someone doing their own package builds: >=20 > Will bulk -c builds (for example) always suffer the longer build > times by not having prior information for reference (because of > the -c)? What sorts of activities would destroy the information > for the next build attempt if that is an issue, making the next > build take the new, much-longer overall build time? For example, > updating the poudriere jail's world? >=20 >=20 > Context for the next paragraph: Just before "using those features in > the ports tree for real" for someone doing their own package builds: >=20 > How will one get to the point of "using those features in the ports > tree for real"? How will a self-builder of packages get to the point > of being able to test the build times in the "for real" context as > well? >=20 >=20 >> bapt >=20 >=20 > Just for reference for official main-arm64-default bulk -c -a (from > scratch) builds: >=20 >=20 > p25bf3a3260c7_s680d34896c3 queued 36447 > and has built 15523 and has 19479 remaining, 134:23:16 so far > (will have built up to 15523+19479 =3D=3D 35002 when done, if it = finishes) >=20 > So: 12 to 13 days (around 300 hrs) as an estimate. >=20 >=20 > The prior longest main-arm64-default official build that completed: > p02dd5021d6f9_s717adecbbb5 queued 36466 > and had built 34853 and had 0 remaining, 163:20:35 >=20 > So: 6.8 days or so. >=20 > Overall: very roughly doubling the overall time when the "for > real" context does not apply. Additional question . . . Which of the following are the stage(s) that take the extra time for an active builder? : check-sanity pkg-depends fetch-depends fetch checksum extract-depends extract patch-depends patch build-depends lib-depends configure build run-depends stage package =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sun Apr 6 21:38: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 4ZW5MB1LRzz5sXhq; Sun, 06 Apr 2025 21:39:02 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from plan-b.pwste.edu.pl (plan-b.pwste.edu.pl [IPv6:2001:678:618::40]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "plan-b.pwste.edu.pl", Issuer "GEANT OV RSA CA 4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZW5M96515z424L; Sun, 06 Apr 2025 21:39:01 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Authentication-Results: mx1.freebsd.org; none Received: from [192.168.7.70] (dom.potoki.eu [62.133.140.50]) (authenticated bits=0) by plan-b.pwste.edu.pl (8.18.1/8.17.2) with ESMTPSA id 536Lcpfq074598 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Sun, 6 Apr 2025 23:38:52 +0200 (CEST) (envelope-from zarychtam@plan-b.pwste.edu.pl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=plan-b.pwste.edu.pl; s=plan-b-mailer; t=1743975533; bh=cv6dZsoFd0kGVcFEaa07MxELZ6DgC82wcBx28xtV7SY=; h=Date:Subject:To:References:From:In-Reply-To; b=t04oDDQb4ec1hOj0oSXzcHpl4l47by7x6sdPmbq/D0Giq+ydHxJEexED3wymRO6Wk z7QymSROu1U+njzJqu4uHHImZOhYK9JLLNqQg82bbzStlg8v4NySzHMgQIAsB8ersB dR9H79uHBn79pXAou9RdXsDCPGTsn8SgDQ8mwQFM4TGATJM8D/U//O3RiHaQOvuOd8 xf81xV+UUaV8KDElJmXssVste/MBwt1m5cGZN3qZelovNFfdk2a0B7b4G8CIC04d8N SBCPwdk6C5FSC9pgJAHsBI964yADU5Xz5NsC9IUaV+EDJ4LzhXkgtyEAmvsJI11iTk ng3bYi+o7MqGg== X-Authentication-Warning: plan-b.pwste.edu.pl: Host dom.potoki.eu [62.133.140.50] claimed to be [192.168.7.70] Content-Type: multipart/alternative; boundary="------------pjd0GBT6v615VfgzHgDnTkXY" Message-ID: <61dfdcac-4893-4c4b-b7e2-48164f1f0c80@plan-b.pwste.edu.pl> Date: Sun, 6 Apr 2025 23:38:51 +0200 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: Implementation of RFC 7217 [A Method for Generating Semantically Opaque Interface Identifiers, with IPv6 Stateless Address Autoconfiguration (SLAAC)] To: Guido Falsi , FreeBSD Current , net@FreeBSD.org References: <45b17684-75ef-4953-b59a-3c3b483ba21b@FreeBSD.org> Content-Language: en-US From: Marek Zarychta Autocrypt: addr=zarychtam@plan-b.pwste.edu.pl; keydata= xsBNBFfi3cMBCADLecMTFXad4uDXqv3eRuB4qJJ8G9tzzFezeRnnwxOsPdytW5ES2z1ibSrR IsiImx6+PTqrAmXpTInxAi7yiZGdSiONRI4CCxKY9d1YFiNYT/2WyNXCekm9x29YeIU7x0JB Llbz0f/9HC+styBIu2H+PY/X98Clzm110CS+n/b9l1AtiGxTiVFj7/uavYAKxH6LNWnbkuc5 v8EVNc7NkEcl5h7Z9X5NEtzDxTOiBIFQ/kOT7LAtkYUPo1lqLeOM2DtWSXTXQgXl0zJI4iP1 OAu4qQYm2nXwq4b2AH9peknelvnt1mpfgDCGSKnhc26q6ibTfMwydp+tvUtQIQYpA6b9ABEB AAHNN01hcmVrIFphcnljaHRhIChQbGFuLWIpIDx6YXJ5Y2h0YW1AcGxhbi1iLnB3c3RlLmVk dS5wbD7CwHcEEwEIACEFAlfi4LkCGwMFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQHZW8 vIFppoJXdgf8D9X3VRFSNaR9lthSx/+uqas17J3FJKBo1xMQsC2a+44vzNvYJSuPGLLJ+LW2 HPVazjP/BWZJbxOYpliY4zxNRU0YCp0BLIVLibc//yax+mE42FND/+NiIZhqJscl6MLPrSwo sIwXec4XYkldkyqW/xBbBYXoIkBqdKB9j5j42Npy1IV/RizOSdmvTWY27ir8e/yGMR1RLr4F 8P5K3OWTdlGy2H2F/3J8bIPBLG6FpaIyLQw4dHSx8V02PYqDxK1cNo2kAOnU8PnZL/AGuMOH iv3MN1VYL8ehcmpBBsrZGebQJxrjY2/5IaTSgp9xHYT70kshuU6Qb97vk1mOjNZxgc7ATQRX 4t3DAQgA10h6RCXuBLMHxq5B8X/ZIlj9sgLoeyfRdDZEc9rT2KUeUJVHDsbvOFf4/7F1ovWY hJbA6GK/LUZeHHTjnbZcH1uDYQeHly4UOLxeEvhGoz4JhS2C7JzN/uRnwbdOAUbJr8rUj/IY a7gk906rktsc/Ldrxrxh7O6WO0JCh2XO/p4pDfEwwB37g4xHprSab28ECYJ9JMbtA8Sy4M55 g3+GQ28FvSlGnx48OoGXU2BZdc1vZKSQmNOlikB+9/hDX8zdYWVfDaX1TLQ8Ib4+xTUmapza mV/bxIsaZRBw+jFjLQHhTbIMfPEU+4mxFDvTdbKPruKPqVf1ydgMnPZWngowdwARAQABwsBf BBgBCAAJBQJX4t3DAhsMAAoJEB2VvLyBaaaC6qkIAJs9sDPqrqW0bYoRfzY6XjDWQ59p9tJi v8aogxacQNCfAu+WkJ8PNVUtC1dlVcG5NnZ80gXzd1rc8ueIvXlvdanUt/jZd8jbb3gaDbK3 wh1yMCGBl/1fOJTyEGYv1CRojv97KK89KP5+r8x1P1iHcSrunlDNqGxTMydNCwBH23QcOM+m u4spKnJ/s0VRBkw3xoKBZfZza6fTQ4gTpAipjyk7ldOGBV+PvkKATdhK2yLwuWXhKbg/GRlD 1r5P0gxzSqfV4My+KJuc2EDcrqp1y0wOpE1m9iZqCcd0fup5f7HDsYlLWshr7NQl28f6+fQb sylq/j672BHXsdeqf/Ip9V4= In-Reply-To: <45b17684-75ef-4953-b59a-3c3b483ba21b@FreeBSD.org> 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:206006, ipnet:2001:678:618::/48, country:PL] X-Rspamd-Queue-Id: 4ZW5M96515z424L X-Spamd-Bar: ---- This is a multi-part message in MIME format. --------------pjd0GBT6v615VfgzHgDnTkXY Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit W dniu 6.04.2025 o 16:49, Guido Falsi pisze: > Hi! > > I have recently implemented and tested the patch at [1], which > implements RFC 7217, about generating IPv6 addresses that are constant > through reboots, but do not expose the MAC address of the machine, not > being in any way derived by those. > > I'd like to get comments, testing and review for this patch, with the > objective of getting approval to commit it to head once it is > streamlined enough. > > BTW I'd like to thank cognet for his suggestions and help with the > patch, in particular his help in finding the correct way to implement > the dad_failures counter. > > > And thanks in advance to anyone willing to give feedback! > > > [1] https://reviews.freebsd.org/D49681 > This is great news for the community ! I've already started testing it on both a desktop and a laptop - which is probably even more valuable, especially since the laptop will be connecting to various networks. If I encounter any issues, I will post comments in the review. Best regards -- Marek Zarychta --------------pjd0GBT6v615VfgzHgDnTkXY Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
W dniu 6.04.2025 o 16:49, Guido Falsi pisze:
Hi!

I have recently implemented and tested the patch at [1], which implements RFC 7217, about generating IPv6 addresses that are constant through reboots, but do not expose the MAC address of the machine, not being in any way derived by those.

I'd like to get comments, testing and review for this patch, with the objective of getting approval to commit it to head once it is streamlined enough.

BTW I'd like to thank cognet for his suggestions and help with the patch, in particular his help in finding the correct way to implement the dad_failures counter.


And thanks in advance to anyone willing to give feedback!


[1] https://reviews.freebsd.org/D49681

This is great news for the community !

I've already started testing it on both a desktop and a laptop - which is probably even more valuable, especially since the laptop will be connecting to various networks. If I encounter any issues, I will post comments in the review.


Best regards

-- 
Marek Zarychta
--------------pjd0GBT6v615VfgzHgDnTkXY-- From nobody Sun Apr 6 21:52: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 4ZW5fx50qhz5sYdK for ; Sun, 06 Apr 2025 21:52:41 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [IPv6:2a00:1450:4864:20::632]) (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 4ZW5fx0vHZz45WN for ; Sun, 06 Apr 2025 21:52:41 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ej1-x632.google.com with SMTP id a640c23a62f3a-ac6ed4ab410so614525166b.1 for ; Sun, 06 Apr 2025 14:52:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1743976360; x=1744581160; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ThMuF4bTy+pu6LN2lIXBxVDcOGbSwI9dMXWItY+kJHY=; b=cj3dODk27p9zeYA4mMU0O0Rsz1IJXBGQh81BPR8jYhrxXbg+lGP9XZ3iFvSYlNcI0p uWOlHLM4uEcrmDA7M9aIZwuSsshFx48D1CNmZPz3CHtH/jUA2YvhAM6xA5vdfFMjJRJz 0S5CusS8bMErnlb+dOhHnV5jdEXC6lQ13TqllLo8ABfbnqeq2lGFO409AXjdPEFu2i4u VlCmzIgMoAkE3RWkG684sGUl5vLOKxp7tx+2x8p4qCbTZ9Qrg91cVBZvmWTOybBI5kf8 GNUXW/Py7nsnF4wNOer+JTD486B53vJIopzx1LQCS3TgkhlJNy/q5mX76pEVYJaSMk9R ErPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743976360; x=1744581160; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ThMuF4bTy+pu6LN2lIXBxVDcOGbSwI9dMXWItY+kJHY=; b=fw5OAMBFj7xBqiI/noKg6xcwwHOlGH+8Mq4T0clwExr4QRgmFYPLiDNw7mg1NSnu0+ gwOz/NeqyTRzvRend0DGQL4wwyY5126pGV1iJDTFUg7OQ9JduNGTEYh+446h1Z2h5WwT Mfr9H00AxWTDcVOeeRXnT6RXOPJIh4NLHpX2KZNJNywL2ChgfnLHfYWsaQVIzMJMQq+o Y3+CEHqZyAg6hDN366HLJnSgV2kh+WgkaQkEJh1ak/VIJv5Jd9dOGAJD4gzExQGGgtqT ujh9uHernk+U+0xdyCj6WKqI2bYG9vZta2uw2TEY+z5AoBjpdYtQO84KKFP13Jnol62U QhLg== X-Gm-Message-State: AOJu0YyJ+DMipW4qCbjy9Rd3aS/jE96TcucWKMQv9dpUPQdlwqOjpRKX h/7nyES6rFekI9xUlmoiGThJVN4rPTtpi2MsaBtbEp331VT4qDcWQdm3g+fZJIUDTeOmyljKWQR 5ikOTK2EV//Hj+7w0MnyRJs+y2A== X-Gm-Gg: ASbGnctgDRjLzg2EweM+M6jwj66HMaWLdtRFx5Kqi1PdFM16l6iar8FR3e7ritTyVV5 l2fNnNDsBVz68TCSR/gXtFogXmAgaY+7OSJdYBKknj5R5wUGs4WnbNO7VwnjnX66ZPQowuF7TCL ph6WiABI+Qz1dw2m3NmHJNLf/9WBqFDPPmBEDXTuziNNG/K+4XLRrbn+eT7/vMqmccyeqw X-Google-Smtp-Source: AGHT+IFTqWHYVuvVz2XZCvPWfAzB1YO2cu5Dauqj2B+20hrux7NWF0XQyeXXM7jTfMJTl/FQ1LaVAXFpsEzhgM106hg= X-Received: by 2002:a17:906:f587:b0:ac7:391a:e158 with SMTP id a640c23a62f3a-ac7d1c69b7dmr1054756266b.59.1743976359401; Sun, 06 Apr 2025 14:52:39 -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: <2rq3bpvhclcipvgg3mo4gml7ysuzbvt6rfnzkprceumzeaeh4b@casrpprm6mgt> <4beaxy5dpajikvafxpjogcxrpyuwwicng5ln5rxbxlbzp2o2g7@ib7wo5jzlte4> In-Reply-To: From: Rick Macklem Date: Sun, 6 Apr 2025 14:52:28 -0700 X-Gm-Features: ATxdqUF4_BqVZzrLuwb5YQFXkVbfsuPk9Dm5uQRvydAg0wDaRiN5PKWLouFQOF4 Message-ID: Subject: Re: Heads Up: commit 2ec2ba7e232d just hit main To: Shawn Webb Cc: FreeBSD CURRENT Content-Type: multipart/mixed; boundary="000000000000664d03063223232b" 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: 4ZW5fx0vHZz45WN X-Spamd-Bar: ---- --000000000000664d03063223232b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Apr 5, 2025 at 5:45=E2=80=AFPM Shawn Webb wrote: > > On Sat, Apr 05, 2025 at 05:36:07PM -0700, Rick Macklem wrote: > > On Sat, Apr 5, 2025 at 4:43=E2=80=AFPM Shawn Webb wrote: > > > > > > On Sat, Apr 05, 2025 at 04:12:15PM -0700, Rick Macklem wrote: > > > > On Sat, Apr 5, 2025 at 9:12=E2=80=AFAM Shawn Webb wrote: > > > > > > > > > > On Sat, Apr 05, 2025 at 08:52:06AM -0700, Rick Macklem wrote: > > > > > > On Sat, Apr 5, 2025 at 8:50=E2=80=AFAM Rick Macklem wrote: > > > > > > > > > > > > > > On Fri, Apr 4, 2025 at 6:27=E2=80=AFPM Shawn Webb wrote: > > > > > > > > > > > > > > > > On Sat, Apr 05, 2025 at 01:04:25AM +0000, Shawn Webb wrote: > > > > > > > > > On Fri, Apr 04, 2025 at 05:40:21PM -0700, Rick Macklem wr= ote: > > > > > > > > > > On Fri, Apr 4, 2025 at 10:50=E2=80=AFAM Shawn Webb wrote: > > > > > > > > > > > > > > > > > > > > > > On Thu, Apr 03, 2025 at 06:12:59PM -0700, Rick Mackle= m wrote: > > > > > > > > > > > > On Thu, Apr 3, 2025 at 4:52=E2=80=AFPM Shawn Webb <= shawn.webb@hardenedbsd.org> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Apr 02, 2025 at 01:51:26PM -0700, Rick Ma= cklem wrote: > > > > > > > > > > > > > > The commit 2ec2ba7e232d just hit main. I do no= t think it will > > > > > > > > > > > > > > cause problems, but it is fairly large. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Man page updates will be done as separate commi= ts. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hopefully this will not cause grief, rick > > > > > > > > > > > > > > > > > > > > > > > > > > Hey Rick, > > > > > > > > > > > > > > > > > > > > > > > > > > The patch review test plan mentions a patch to ZF= S itself to support > > > > > > > > > > > > > named attributes. Is that patch available somewhe= re? > > > > > > > > > > > > The ZFS patch is currently in phabricator as D49654= . > > > > > > > > > > > > Feel free to review it. > > > > > > > > > > > > > > > > > > > > > > > > It can also be found at: > > > > > > > > > > > > https://people.freebsd.org/~rmacklem/zfs-xattr.patc= h > > > > > > > > > > > > (this is a smaller diff which can be applied to an = up-to-date main src > > > > > > > > > > > > tree easily) > > > > > > > > > > > > > > > > > > > > > > Hey Rick, > > > > > > > > > > > > > > > > > > > > > > I applied that zfs patch, but trying pathconf(2) on a= file on a ZFS > > > > > > > > > > > dataset with xattr=3Don (which seems to be the defaul= t) returns 0. Am I > > > > > > > > > > > doing something wrong? > > > > > > > > > > > > > > > > > > > > > > =3D=3D=3D=3D BEGIN LOG =3D=3D=3D=3D > > > > > > > > > > > hbsd-current-01[shawn]:/home/shawn/tmp $ ./xattrtest = xattrtest > > > > > > > > > > > xattrtest: Named attributes not enabled: No error: 0 > > > > > > > > > > > hbsd-current-01[shawn]:/home/shawn/tmp (1) $ zfs list= /usr/home/shawn > > > > > > > > > > > NAME USED AVAIL REFER MOUNTPOINT > > > > > > > > > > > rpool/usr/home 10.4G 71.4G 9.85G /usr/home > > > > > > > > > > > hbsd-current-01[shawn]:/home/shawn/tmp $ zfs get xatt= r rpool/usr/home > > > > > > > > > > > NAME PROPERTY VALUE SOURCE > > > > > > > > > > > rpool/usr/home xattr on default > > > > > > > > > > > =3D=3D=3D=3D END LOG =3D=3D=3D=3D > > > > > > > > > > > > > > > > > > > > > > That xattrtest application is yours from: > > > > > > > > > > > https://people.freebsd.org/~rmacklem/xattrtest.c > > > > > > > > > > No idea. It works for me. You used up-to-date kernel so= urces? > > > > > > > > > > (Check that VIRF_NAMEDATTR is defined in sys/sys/vnode.= h.) > > > > > > > > > > Oh, and one more thing to check. zfs_xattr_compat needs= to be non-zero. > > > > > > > > > > (It's found in sys/contrib/openzfs/module/os/freebsd/zf= s/zfs_vnops_os.c. > > > > > > > > > > It's initialized to 1 and I don't see anything that set= s it to 0?) > > > > > > > > > > > > > > > > > > It is indeed set to 1. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The only thing I can think if is, if you changed xattr = to on, you need to > > > > > > > > > > reboot (or at least remount) to get it to take effect. > > > > > > > > > > (Maybe try setting it to "dir" and then reboot/remount.= Maybe there is > > > > > > > > > > a difference between "on" and "dir"?) > > > > > > > > > > > > > > > > > > Yeah, tried rebooting and still no go. Note that xattr de= faults to > > > > > > > > > "on" in FreeBSD by default. My src tree is synced up to F= reeBSD commit > > > > > > > > > 7e70d94acd68b3ac6b45f49d4ab7a0f7867c3ea7. I brought in th= e ZFS patch > > > > > > > > > you linked to. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Or, did you build zfs.ko some other way than as part of= a kernel build? > > > > > > > > > > (It needs the patched .h files in the kernel sources, n= ot something in > > > > > > > > > > /usr/include/sys > > > > > > > > > > that has not yet been updated.) > > > > > > > > > > All the ZFS changes are #ifdef'd, since OpenZFS require= s the sources > > > > > > > > > > build for older kernels. (Basically #ifdef'd on that VI= RF_NAMEDATTR mentioned > > > > > > > > > > above.) > > > > > > > > > > > > > > > > > > Perhaps I need to do a clean build. I'll try that and rep= ort back. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > It does remind me that I need to try a build of zfs.ko = by doing a "make" in > > > > > > > > > > the module directory. > > > > > > > > > > > > > > > > > > > > You can try the attached trivial patch and see if it sp= its out "pathconf ret=3D1" > > > > > > > > > > on the console. > > > > > > > > > > > > > > > > > > I'll try that after a clean rebuild of the kernel. > > > > > > > > > > > > > > > > Clean rebuild didn't resolve it. However, I made some progr= ess. > > > > > > > > > > > > > > > > I created a dataset specifically for this since I can't rea= lly unmount > > > > > > > > my /usr/home dataset, so my example down below is a bit dif= ferent than > > > > > > > > the previous example I gave. > > > > > > > > > > > > > > > > The xattr property is set to "on" for the dataset. However,= it's not > > > > > > > > mounted with the xattr property. In order to get it to work= , I had to > > > > > > > > run the following commands: > > > > > > > > > > > > > > > > =3D=3D=3D=3D BEGIN LOG =3D=3D=3D=3D > > > > > > > > $ sudo zfs umount rpool/scratch/xattr > > > > > > > > $ sudo mount -t zfs -o xattr rpool/scratch/xattr /scratch/x= attr > > > > > > > > $ zfs get xattr rpool/scratch/xattr > > > > > > > > NAME PROPERTY VALUE SOURCE > > > > > > > > rpool/scratch/xattr xattr on local > > > > > > > > $ mount | grep xattr > > > > > > > > rpool/scratch/xattr on /scratch/xattr (zfs, local, noatime,= nfsv4acls, named attributes) > > > > > > > > $ mount | grep named > > > > > > > > rpool/scratch/xattr on /scratch/xattr (zfs, local, noatime,= nfsv4acls, named attributes) > > > > > > > > =3D=3D=3D=3D END LOG =3D=3D=3D=3D > > > > > > > > > > > > > > > > So it looks like FreeBSD does not honor the xattr zfs prope= rty, > > > > > > > > otherwise you would see a whole bunch of datasets mounted w= ith the > > > > > > > > "named attributes" flag in that last `mount | grep` command= . > > > > > > > I've looked at this a little more... > > > > > > > There is a function xattr_changed_cb() that updates the xattr= property > > > > > > > information. > > > > > > > It gets called when "zfs set xattr=3DXX " is don= e or when > > > > > > > the mount option "xattr" is set. > > > > > > > > > > > > > > The question seems to be "Why was the stuff not correctly set= for your file > > > > > > > systems, although they show xattr=3Don?" > > > > > > > > > > This is indeed what I was inferring. xattr has been set to "on" s= ince > > > > > the pool's creation as far as I can tell. Until experimenting wit= h > > > > > your patch, I didn't really even know the xattr property even exi= sted. > > > > I was able to reproduce this with a fresh zpool. > > > > Although it reported "xattr on", that is not really accurate. > > > > > > > > I stuck a printf() in here (line#853-861 of > > > > sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vfsops.) > > > > > > > > /* should either have both of these objects or none */ > > > > error =3D zap_lookup(os, MASTER_NODE_OBJ, ZFS_SA_ATTRS, 8, 1, > > > > &sa_obj); > > > > if (error !=3D 0) > > > > return (error); > > > > > > > > error =3D zfs_get_zplprop(os, ZFS_PROP_XATTR, &val); > > > > --> The printf here shows that error =3D=3D ENOENT. > > > > if (error =3D=3D 0 && val =3D=3D ZFS_XATTR_SA) > > > > zfsvfs->z_xattr_sa =3D B_TRUE; > > > > > > > > The printf() of error showed ENOENT. So, "xattr" actually does not > > > > exist. "zfs get xattr " calls it "on" but that's not a= ccurate. > > > > > > > > As root, I did: > > > > # zfs set xattr=3Ddir > > > > - reboot > > > > > > > > This makes it work, although the above call still returns ENOENT. > > > > It looks to me like zfsvfs_init() gets called from zfsvfs_create() > > > > right at the beginning of zfs_domount(). > > > > Later in zfs_domount() it calls zfsvfs_setup()->zfs_register_callba= cks(), > > > > which now finds the property (because of the "zfs set xattr=3Ddir <= file-system>") > > > > and registers it via dsl_prop_register(). > > > > > > > > I don't know if the above is correct? > > > > Personally, I would prefer to see "zfs get xattr " rep= ly "not set" > > > > instead of "on". > > > > > > > > rick > > > > > > > > > > > > Setting the property makes it work, but only after rebooting > > > > (a umount/mount would probably have the same effect, I think?). > > > > > > So I wonder why neither an unmount/mount nor a reboot causes `mount | > > > grep "named attribute"` to fail for me. HardenedBSD doesn't have any > > > changes to ZFS that would cause that kind of behavior. I have to > > > unmount, but manually mount with `mount -t zfs -o xattr ...` in order > > > to access the new feature you wrote. Weird. > > So, you have done > > # zfs set xattr=3Ddir > > followed by a reboot and it still doesn't work? > > Correct, even a reboot does not work. No idea. If you apply the atteched little patch (just printf's) and post what gets printed out (when a mount that doesn't work is done), it might help explain it. rick > > -- > Shawn Webb > Cofounder / Security Engineer > HardenedBSD > > Signal Username: shawn_webb.74 > 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 --000000000000664d03063223232b Content-Type: application/octet-stream; name="debugzfs.patch" Content-Disposition: attachment; filename="debugzfs.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_m966hjd30 LS0tIHN5cy9jb250cmliL29wZW56ZnMvbW9kdWxlL29zL2ZyZWVic2QvemZzL3pmc192ZnNvcHMu Yy54eHgJMjAyNS0wNC0wNiAxNDozNDo0NC4wNjY4NjcwMDAgLTA3MDAKKysrIHN5cy9jb250cmli L29wZW56ZnMvbW9kdWxlL29zL2ZyZWVic2QvemZzL3pmc192ZnNvcHMuYwkyMDI1LTA0LTA2IDE0 OjM3OjU1LjEyNzQ1NjAwMCAtMDcwMApAQCAtNTAwLDYgKzUwMCw3IEBAIHhhdHRyX2NoYW5nZWRf Y2Iodm9pZCAqYXJnLCB1aW50NjRfdCBuZXd2YWwpCiAJCWVsc2UKIAkJCXpmc3Zmcy0+el94YXR0 cl9zYSA9IEJfRkFMU0U7CiAJfQorcHJpbnRmKCJ4YXR0cl9jaGFuZ2VkX2NiOiBuZXd2YWw9JWxk IHpmbD0weCVseCBzYT0lZFxuIiwgbmV3dmFsLCB6ZnN2ZnMtPnpfZmxhZ3MsIHpmc3Zmcy0+el94 YXR0cl9zYSk7CiB9CiAKIHN0YXRpYyB2b2lkCkBAIC03NDMsOCArNzQ0LDEwIEBAIHpmc19yZWdp c3Rlcl9jYWxsYmFja3ModmZzX3QgKnZmc3ApCiAJICovCiAJZXJyb3IgPSBkc2xfcHJvcF9yZWdp c3RlcihkcywKIAkgICAgemZzX3Byb3BfdG9fbmFtZShaRlNfUFJPUF9BVElNRSksIGF0aW1lX2No YW5nZWRfY2IsIHpmc3Zmcyk7CitwcmludGYoImJmciBkc2xfcHJvcF9yZWdpc3RlciBlcnI9JWRc biIsIGVycm9yKTsKIAllcnJvciA9IGVycm9yID8gZXJyb3IgOiBkc2xfcHJvcF9yZWdpc3Rlcihk cywKIAkgICAgemZzX3Byb3BfdG9fbmFtZShaRlNfUFJPUF9YQVRUUiksIHhhdHRyX2NoYW5nZWRf Y2IsIHpmc3Zmcyk7CitwcmludGYoImRzbF9wcm9wX3JlZ2lzdGVyIGVycj0lZFxuIiwgZXJyb3Ip OwogCWVycm9yID0gZXJyb3IgPyBlcnJvciA6IGRzbF9wcm9wX3JlZ2lzdGVyKGRzLAogCSAgICB6 ZnNfcHJvcF90b19uYW1lKFpGU19QUk9QX1JFQ09SRFNJWkUpLCBibGtzel9jaGFuZ2VkX2NiLCB6 ZnN2ZnMpOwogCWVycm9yID0gZXJyb3IgPyBlcnJvciA6IGRzbF9wcm9wX3JlZ2lzdGVyKGRzLApA QCAtODU5LDYgKzg2Miw3IEBAIHpmc3Zmc19pbml0KHpmc3Zmc190ICp6ZnN2ZnMsIG9ianNldF90 ICpvcykKIAkJZXJyb3IgPSB6ZnNfZ2V0X3pwbHByb3Aob3MsIFpGU19QUk9QX1hBVFRSLCAmdmFs KTsKIAkJaWYgKGVycm9yID09IDAgJiYgdmFsID09IFpGU19YQVRUUl9TQSkKIAkJCXpmc3Zmcy0+ el94YXR0cl9zYSA9IEJfVFJVRTsKK3ByaW50ZigiemZzaW5pdDogemZsPTB4JWx4IHZhbD0lbGQg ZXJyPSVkXG4iLCB6ZnN2ZnMtPnpfZmxhZ3MsIHZhbCwgZXJyb3IpOwogCX0KIAogCWVycm9yID0g c2Ffc2V0dXAob3MsIHNhX29iaiwgemZzX2F0dHJfdGFibGUsIFpQTF9FTkQsCkBAIC0xMjY1LDYg KzEyNjksNyBAQCB6ZnNfZG9tb3VudCh2ZnNfdCAqdmZzcCwgY2hhciAqb3NuYW1lKQogCWlmICgo emZzdmZzLT56X2ZsYWdzICYgWlNCX1hBVFRSKSAhPSAwICYmICF6ZnN2ZnMtPnpfeGF0dHJfc2Eg JiYKIAkgICAgemZzX3hhdHRyX2NvbXBhdCkKIAkJdmZzcC0+bW50X2ZsYWcgfD0gTU5UX05BTUVE QVRUUjsKK3ByaW50ZigiemZzX2RvbW91bnQ6IHpmbD0weCVseCBzYT0lZCBjb21wYXQ9JWRcbiIs IHpmc3Zmcy0+el9mbGFncywgemZzdmZzLT56X3hhdHRyX3NhLCB6ZnNfeGF0dHJfY29tcGF0KTsK ICNlbmRpZgogCiAJdmZzX21vdW50ZWRmcm9tKHZmc3AsIG9zbmFtZSk7Cg== --000000000000664d03063223232b-- From nobody Sun Apr 6 23:43: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 4ZW87N408bz5sDHF for ; Sun, 06 Apr 2025 23:44:00 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic304-25.consmr.mail.gq1.yahoo.com (sonic304-25.consmr.mail.gq1.yahoo.com [98.137.68.206]) (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 4ZW87L4KKhz3WTm for ; Sun, 06 Apr 2025 23:43:58 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=SZohvuLS; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1743983036; bh=7mmTPt0nWRZxUldiR6tW53WPOv4jxoDuXWXL/f1MESU=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=SZohvuLS/07dGBd7V5zRGRHDAs6IZMeLC5yNYgGJ12YtkXj0F7MIQCp66jYZ9C9t8R5PWM9ksOu4bG21Q/u7UWx8eSYye5ifL6gB3YLdzXyNW9f8pdzyZfd8BbY0WD/mVjWuYBobxIQEVpz8vkompbh+hUfHCOt3lycbU7KwIh+FhmhmyRFaC64C2QcNNPOXRgojGgzb+OHhzwpu58ip7UtVlX5aKiybrIHinmoalIg+U3Lt8lXF1P4UCI1cV2iKIb7Y9ALzUGLTCQaL69V+YDAzBALgzFh9BpSRRZlzLL9z1sJbpgskCVUqmw/JeNxvBFkkOIBEn+NwyjopwShwpA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1743983036; bh=sCUCUDYb21D94Bk9BT00Vfle7II7N4Xne3fjtyMqRab=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=e9sHHTMMBBhRosbezRKj9kmg6TU+B2xxbjNsL4j3bkrmyVaEhhIra2vTygIxAP784gW1lt4PItW4jIkaM1qE2Es02KOpg2C1+r0c+vP0/qmcjSHfax9Xb2Ta7JtiDww0Q4ecLDAqXz3OB+ZE/S10ZCfWz4M3izeRf8IUe4405kj/qfOJPaQu+hvp7iKB3VfvQ2w5vNRD06EtYS8uRLBqkG9jdC95siJKPgQ55LOARhHYis4TVP2oM3RBXOdEOurP4Fl6fo6jAE0VZtJqR6enfQZQdJPuIJxdC+laJrfckOvdb+T5yx5imOCu4NBqYxN7GQqsCWyKVBqU73V7OnSc4g== X-YMail-OSG: ppYbDf0VM1mRduO26HP756eARv8O_scoAUr0GqrzTtqY2kNK1RNR7LYnmArdop6 gVk8pDWk3K7DWs98F0EcNZJqQR77TkjU6HwTIPgP.t0LUCMcgB.tFdCorKYDLX303UNGntkVpsjI iyCs_L27h0YDvck5lPbYgTOPxjUTFHoJw09WMnKkWQQnK4RrH_wBgasJKAo6a2Auuka9Cfz2_t_g LCwJH4fEuME3PQWBN8QQSG497JI4Mx3SYwVbQPtLUbql9S3C7rf7TehZpFUj0lYkTdt6ni3Co2_a 8voEo49NKOBhU2AIE58f35Ldk0iNrZSL9fS9Vy1SZMvfJmPW1i8DFwviBOXjYtLdHEfDid8pktDn k3LNMetn21cIwvUadABR4AV9p67bd60W1OTVbLs60LLLVWgzvqxBlwCqdkzzXoVI7nu5oofb__lY GNjuGKjvSXgvZVhWrq0TBtPnsGb31piUtdLw3T_k2UYbMHz2PCa9CNHh.bkGYIRiDmtgMApFN1LA 3JVfwFlGB8clU5kRGc4ySO9rE41ofl1fgK11bNhOuqZPFnccGshTW3v1AZLfAzQLJ2pLBVt6ywpd AZ6QWADcNR0uNPpMAa03lWu5Tux2ccpVklYd9Zes8jKke7HkFx3cEAtVjF2pfavqtUR0OPfLTYkL dKSbQhBGs9Pe4XMJ.8gFA4mtitAqrr_pu7tJ_EUzE_MCDTFRphNdx0y6pMQKtI4G_X8eZmjl5Iuj QHC.1kcR70_XCfq7iV.SAfDwjMPIrZVQrknfAHmwlMMUb0910LxGawew2Ie0CQ0pWP069wBIcvmA rKM3I2P2vbOO.23QMSzzz6DvMAX_vIdlotxR.O8QpNZjrRS.i.Bed0g9.CNzyZMc3j_OoVLfgqdZ lo4JlYAJJrfz2zsnLOjic_IrIXxHkiV_DMxh0LFW6FcGaNa2IKrtUDw6LdTJverlvKM0qQuhF.mA AV4xkIEo7Y_TrFaVUTNozmCwMa9uVRmywFkalliRR5SVbXXFvuQzqdf.kJWgFNeLgehb.kPaznVE .lE.uTONnNbuTZiq_.2.uyL8rPr08ItzwEkrCXi7hQylZgqWH7mnXGD.wHWILvQIbOs6dondsMuV UxZUxnOtDL9YKcoWi783Sa463aKTk.opdNxheemCE6kggRuUxqVzpcbBE5xxCZNkoSrVYfP2D7aX wpLo66ZdenTy3yLheuZFuYCHv9eTjeGF_VADIDjjzoGR3PolMIrk.1WfJcqdkOqxh63Nn1yzf2Qa q9PokF3CVaEP.S0GDDXH0IXQauDtJ3iKeXBi3d0woCm25ESEbt0MSyrBzFtJaftPJ0htf23v8ciE zHOt1RBb0k3U5WnpxHk7QHQddTZZw0el9_Q38y_bPM5OlAJ6bYuBYBurT1ZSDiO9BiMTSAy5zMxC qG_IF6oY_b_.QR_QtwCYRn0kxYq7LEPyJPy9tDGjMF0Ce0f28gd_or3JHKr4M_4rtUjUSn9BGARW D6WH8h6wapaEs7bYTzG5PIYFK3j9WG5x8fIdHkj2OG6QcEUEzIt.ENMNplOx_F1vTGsEXICOvz2a BQEZq6lepqGaxX2qMrah_ywoEx_hsglDeeB778Big_9qO0JBwK8UiNpNnwUvaxrDzvGtBKU2kNkq GXPhm0nrZ.bj1ygw_nCOYHlvofqorwGxmbV7RaiZsibvXmybBq6Zj3tHZEXseIdoTG9jQLT4rRB8 9.ficBGUF6.f1JtFBUrsL21gekLiyRLOBkDMorzoid9Z0a.7tGnn.EhKN.J5cNTWFl5i4x0kohAN lGntriT6FoxxLDwOqKXM0HLLmFOXX0XDg9s_uMeeFZ5cLfTER5sY2MRE0n8LWc4BdxNNq31_ACA2 mgEE.WtUiFU3Ov3oIgTDVQE3V7wpwy1BUmMaLTSYBoUF6BMnK394T8DOTm.OVPM1XQkfoC49RrJF SiYAZHj7wcr6RGO4XSkNdnyRyHZKztv_zq0eem.wkQvHe0W8N3lfZnXBXMNHZMZdjtio7y_6E7fL .GpJhQJn6q4BP.c1q9UuiiivhhzJctQm546ljjt01ItzOeeQNfMgSAZ8eyHrdWbkxWYVrVIvvCtd .k91TBvBughbcE6i8dPYXaUGwKZpHngW.CRkB0OliHTWuNiMMeeRzAVsd4E7j2DYfX0lXkJJJf9p 7d.Mw8HAZS9IsFCUl2h.ZONG.Dkd7BITRLPktX9RIMm.uJLqesxdH4b9c.UEofij1gKDpMSLjZFa Sk5KNAx_9_2b8JbjbivURQIeFccN5w1r90873aOJJvIonkPp4X_DhFhYft0yv8KrvLNTEpJqQPoy 1eMneM6FJRg-- X-Sonic-MF: X-Sonic-ID: 020607ef-ff6b-4c49-a9ba-503b3ad70260 Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Sun, 6 Apr 2025 23:43:56 +0000 Received: by hermes--production-gq1-5c477bf655-fdl68 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID a9fd625be398ac396a972a1c91a4dd14; Sun, 06 Apr 2025 23:43:56 +0000 (UTC) Content-Type: text/plain; charset=us-ascii 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.500.181.1.5\)) Subject: Re: UPDATE: pkg 2.1.0 looks to be making official bulk builds of packages take much longer [it is more complicated then that for aarch64] From: Mark Millard In-Reply-To: Date: Sun, 6 Apr 2025 16:43:45 -0700 Cc: FreeBSD Current , FreeBSD Mailing List Content-Transfer-Encoding: quoted-printable Message-Id: <366E27FD-FA5B-4BF8-B6C4-6C495DB289C5@yahoo.com> References: <8E2FBAD3-EF6F-4D99-A340-21F8FD19AE0F@yahoo.com> <84FBBAF8-025E-4B9D-9797-51735567A8DB@yahoo.com> To: Baptiste Daroussin , Konstantin Belousov , Warner Losh X-Mailer: Apple Mail (2.3826.500.181.1.5) X-Spamd-Result: default: False [-4.49 / 15.00]; RBL_SENDERSCORE_REPUT_9(-1.00)[98.137.68.206:from]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.997]; NEURAL_HAM_SHORT(-0.99)[-0.993]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; TO_DN_ALL(0.00)[]; ARC_NA(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; DKIM_TRACE(0.00)[yahoo.com:+]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.206:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.206:from]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_FIVE(0.00)[5] X-Rspamd-Queue-Id: 4ZW87L4KKhz3WTm X-Spamd-Bar: ---- [For the most part the prior history of my notes is not important so they are mostly omitted this time.] It looks like my notes about official bulk package builds taking longer may be from observations of more than one distinct issue, one leading to a very rough factor of 2 and the other not leading to anything like such. I'd reported that main-arm64-default was taking very roughly 2x as long to do its official bulk -a -c (from scratch) style build. This is what got me to classify the time increase as rather significant. It was the first thing that I'd noticed that started my looking around and biased my interpretation in later looking. The recent information for main-arm64-default was: > Just for reference for official main-arm64-default bulk -c -a (from > scratch) builds: >=20 >=20 > p25bf3a3260c7_s680d34896c3 queued 36447 > and has built 15523 and has 19479 remaining, 134:23:16 so far > (will have built up to 15523+19479 =3D=3D 35002 when done, if it = finishes) >=20 > So: 12 to 13 days (around 300 hrs) as an estimate. >=20 >=20 > The prior longest main-arm64-default official build that completed: > p02dd5021d6f9_s717adecbbb5 queued 36466 > and had built 34853 and had 0 remaining, 163:20:35 >=20 > So: 6.8 days or so. >=20 > Overall: very roughly doubling the overall time when the "for > real" context does not apply. It turns out that the above may well be essentially independent of the pkg 2.1.0 related time changes. I did a local test of building my usual aarch64 ports from scratch prior to updating the ports tree to have pkg 2.1.0 instead on 2.0.6 . I then updated to use an updated ports tree that has pkg 2.1.0 and did a test for that context. I got nothing remotely like a factor of 2: pkg 2.0.6 based /usr/ports/ : [01:04:57] [release-aarch64-default] [2025-04-06_12h23m09s] [committing] = Time: 01:04:46 Queued: 264 Inspected: 0 Ignored: 0 Built: 264 Failed: 0 = Skipped: 0 Fetched: 0 Remaining: 0 vs. pkg 2.1.0 based /usr/ports-alt/ : [01:07:28] [release-aarch64-alt] [2025-04-06_14h16m21s] [committing] = Time: 01:07:27 Queued: 265 Inspected: 0 Ignored: 0 Built: 265 Failed: 0 = Skipped: 0 Fetched: 0 Remaining: 0 So: 2 min 31 sec or so difference for overall somewhat over an hour, i.e., 151 sec or so. That is under 1 sec per package built. At 1 sec or so per package for more like 34853 packages, that would be more like 9.68 hrs or so added overall. (Something I should have noticed and reported earlier.) That may well be more like what is going on for pkg 2.1.0 related extra time. The test was in an apple silicon M4 MAX context under Parallels on macOS. My build configuration is more biased to allowing high load averages than the official builds are as well. Also: Host OSVERSION: 1500034 Jail OSVERSION: 1402000 So: Host was before 1500035 (which may not be significant). Also, it is a NO-DEBUG based personal build of the kernel that had been booted. That build was based on use of -mcpu=3Dcortex-a76 . The booted world was of an official PkgBase install. The poudriere jail was also via an official PkgBase build rather than a personal build: # poudriere jail -l JAILNAME VERSION OSVERSION ARCH METHOD = TIMESTAMP PATH release-aarch64 14.2-RELEASE-p1 aarch64 pkgbase = 2025-03-12 21:11:39 /usr/local/poudriere/jails/release-aarch64 . . . (Note: "poudriere jail -j release-aarch64 -u" does not seem to update the "-p1" part of VERSION.) For aarch64, only main-arm64-default ( p25bf3a3260c7_s680d34896c3 ) has started a from scratch build. The closest aarch64 alternative is the large build: 134arm64-quarterly ( 359bbf7fc5af ) that queued 28018 and has built 12870 and has 13677 remaining: 92:24:15 That suggests 180+ hours overall for less than a from-scratch build. That is more than the prior largest time for a completed 134arm64-quarterly build: 125:58:32 --and by far more than 10 hours. 134arm64-quarterly ( 2cbed7722168 ) that queued 36335 and built 34903 and had 0 remaining: 125:58:32 So there being an aarch64 timing issue is not limited to debug kernel builds, although the factor may be somewhat smaller than 2 for a non-debug kernel and world being used. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sun Apr 6 23:55: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 4ZW8PF66fVz5sFQ1 for ; Sun, 06 Apr 2025 23:56:01 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-55.consmr.mail.gq1.yahoo.com (sonic315-55.consmr.mail.gq1.yahoo.com [98.137.65.31]) (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 4ZW8PD0vswz3bpy for ; Sun, 06 Apr 2025 23:56:00 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=uGx6coEK; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1743983753; bh=PvG+ZCDC1hy2qevq5ik9WX3E3jjR0gWGuj5JNjlccH8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=uGx6coEKa6UjT08oKRUxi/b5AnCSffhu1wRBgdltt+QMfWjerUL1pOY5PM+rnTz6Wx1g6mS6hP/Shhna0vVMjoSaYoiNnOnrOQxc6bISaXrhT0rHFGmHQBUWeRaGl42tus92UxmFRM7zSjrypxt20jXi3EL2IVw5WVumo9xi7NVPG2vfHcquqNoEzZQhU+xDGyuLmw7Es3640w+Brr5TH4ffxAuxPwyAoM9OAq5ExqsbDg9PHobGfsCpZl8eRIiMwkZyt2ya6bOmb5ghzDUO/kGwrJ+FmFTsogUfG8ezAL/N86jWU6Fs96WEYMvkFB+eaEJq66uUBNp64TZ1XkLI0Q== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1743983753; bh=3gAggIK+GW2LUuKgFnUYxGWm5e9ykI+nPmlit0colyE=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=LiZFOoq/kyhOHXy9+vViZbjnY9w3Fgf8kjExWpp1Wuu8DhFQy//vwxfCJFgNewltXPhyp7NF/SyhIYczE6zVIr4p9VMqFvUcgecm5F6t5Xqgd6NJCAQ3qv5rJxqgYnybZh5qqGZQ8scbPemNTnDR58va67tzJ4aUOESsxlPx5zd2brSzjOYMLtPIDxDDz3OBhV3uPqceEcJy81SevsvqZiuSkVvE9nmxgLKkBFckiRSbWJ9hBUm2iTjZFtUquZcg3vGO27t4JlfbfdC2svDBowjK0CXX/1+SNd98wZg3Hd0Zg25HRoqpEwO5EF1XHNCJPFSvSaouvPTpm7i/HeUZSw== X-YMail-OSG: 39gFZ_cVM1mzevcsigaUgXLtJVFScGd6SAIzYnvtEmwPJoUlHZimavqwFY2NGTA ZaYgOrTj2OA3gtzsCYNYKX6uxqTAWYPmrUZk9Ahr5D5B3tOLmkkW1dwEPX6T.5EAOwStVzDn5wlE 2pGDHsq_Amw7S3QSB4dQPmNwzfT7TmdTEsKBZrTyCRzing8ARMkhHyLZ4O.iT5o5q.w6dhTUvEUk 4IbaB_prJ_no3Mq_48ihR7Xk05DmBE7MTf444s07KGeZA8x01h86yfw4dCcrUP_sBqoJtH5ondEe QURGNj2UDiVvhUf1N0I_HM5AdkDfj5NAk6oKFicc87QByB1UksfUFLwHbo5rPvTxJ4TKDri5GRCM BDXxsvpVBHP7JmTYgRUmDEKLBOIGy_2QmrNDk_8x6loWP5wJlu3XaUiReK_rKKiKaUz4a9UyhdHI LFGdY8uHebMMwALBMW_KhJdf6pc8pfzaFPWYgExmXVfH.Ox7t9WHnKbwZj0Q4df3SRftIzwPamtr 1jlEnMSaKFnF4LseuLT1qAL89OsZbH1kwr5HhHhCiiftbOTvrsKgF.t3krE00n0Q4r1Y1oULyuON U_pn.e0M2kFAQn.Ps8ewtGkGywDOlpSnv7ufAP63wuOs.pTp9ghOKDRA.WWAXLI6jFbyC0LeEmJ_ GwiPQ_H_7CJbuLQ9rYXoVmeNoB0lDNl.faY0hMTYg2h1n.2Qkxbd77KDCmXrxv4lSmG8oQqgMX7M vdjawfQWcn3FyMBBgIrmf6n6i3n5ma6XIAkmQanUwXdFnSTHTP3SxvmKWr5q_Q7R054ZcjdrcCdr EXgva4zCs1kc2ub6MNgAYTNqOVGDyE06zJdj7z0pra4JDPngZQ4AcDgtMotKQlSq.KOw5M0cGvbG pQdU9.JpJoYETOWsAbCXroG3OoAZ99m0EZAyyfEHEo6IjiF7Nh8.uirBpH0CK0QoVaQfkUBsZYpU m3PqjXrQxXkJrkDdUGpR5hnbOU4I5Y2TchpD.gMNy75e1OEjFvZ2xyv9lsl.hkDECJWXZEbTR8c4 SRSgv1hK6geEUm65wiXSbU1wWnm47Y6cIX_KeFXgIk54.ePgsjcJeyLv6wEMY5_uw7JrvRXUDe9D QKC5trwfL4VNJJKPAGsjYi9rIUTQvxkARm8PzwWELv9RQYRY0QNYAd_GlslZ52_LtoNURrr.JfUm kGEeRDuU9zFt6xFaErARnG2caQqg3ePCOuFpV.AXbhJVqaG41WXc90LJ3WckvykR.YmIfWqkMOO0 raQm6aMvd4FZBayOGvsPRCBXwW_nT9MJOrMT7EtdzHUCLCldkk6n8VSPYOhUu9e6w_TijgHWma.H SU3GyEE5_o2uOUatv_08jw7bqMquKF2ci5LSJ89xDNHZ1sm4v2QMgvR4hPP9rd7oH9Ff1kPTNqHm C9GczuSyqvzNr0UogT6x7F4jpeNyhTkTtSoogAU.bHCl_ZMjNcb3IJpHjZ02lGzCOXr8aXbJe4ws XGfm7lIMtwiiUw5R4xm_qVYDseiXvGjtTV4oJJkMYojo_mc2QAxXS5FRU6IG0muyicopLiBKV_yJ C6Tw4XF9LXeWSv9nMiJpsH0F2SvEsKhWE5tYRdQvD1Hwjhb1LCSrPsAlAyWmQEOt1nfjtCkq2huK _5UHlzKXFQTj1GIipeWwMzVyAG.zgkxRF5qW5QFe.EqTGoXDI3X0K8kWpDnc5wejwKHPrsL62vyY VHtUiTgXxu9EBsP0y6x.XuudZqa6sbBNTMTS4IIfCBf65Zgoyl2pBR.oSZwignj5rJLc9_zDaurn VrgLMQXdMVRLYTGA_MMIoJxoK_m5dowHXG_31Q9QXJBJlJftKXtrNx7oXX0fJ.QVhLVcvV_Sp4oQ 8ZVazxsIO9h_4zobOh26aoIu64ESoBfiAN9s.Z8OSh8_uXgVB9XBYgqjxQ.mdJMH3PLkfIA6Cb0r ojWHUkGJSLnQSg.nA64yNdUKWW5SwWYSerWhwt5b0asST6dgJDRxisml6idLAY.s2T0_uQgNFlZ7 fVgqTLptH6Cd.v_AQRT4Z8WX7PBrBNsRqXnlfqZMOXDG1uVd1_KwT1.AqvpoBQZB4sWpqiSORYeO IfRe2Ytv.GAoHx_.CJYID5EdtLwHnu1jEbgOeY7PItR3Vy7TSHStxukcQnC3LMYP4w50DiFh.WDK Gsmi49gExW_X7lOIL0vCSGoWM.b36qqRo3HFdShLzbhh0D1fGnSoyJp1aJ4n2sSBZZCXhNLu19uD he1RTiOKG_RCXqllZSzO2uW5RfFY7HTIWfQ3mjSVsIwslHK7O7jk6zAT7rsG4DIB3zwc_RrpBjB_ F6Yg0vqkxD8UjwQ-- X-Sonic-MF: X-Sonic-ID: ea7718d5-335a-4add-8549-f05ef3358b01 Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Sun, 6 Apr 2025 23:55:53 +0000 Received: by hermes--production-gq1-5c477bf655-7nzz9 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 0d39677a63a2aa28c23f3dd3e028958d; Sun, 06 Apr 2025 23:55:51 +0000 (UTC) Content-Type: text/plain; charset=us-ascii 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.500.181.1.5\)) Subject: Re: UPDATE: pkg 2.1.0 looks to be making official bulk builds of packages take much longer [it is more complicated then that for aarch64] From: Mark Millard In-Reply-To: <366E27FD-FA5B-4BF8-B6C4-6C495DB289C5@yahoo.com> Date: Sun, 6 Apr 2025 16:55:41 -0700 Cc: FreeBSD Current , FreeBSD Mailing List Content-Transfer-Encoding: quoted-printable Message-Id: <5B20A794-DA42-4F46-A80C-9A262C0382B5@yahoo.com> References: <8E2FBAD3-EF6F-4D99-A340-21F8FD19AE0F@yahoo.com> <84FBBAF8-025E-4B9D-9797-51735567A8DB@yahoo.com> <366E27FD-FA5B-4BF8-B6C4-6C495DB289C5@yahoo.com> To: Baptiste Daroussin , Konstantin Belousov , Warner Losh X-Mailer: Apple Mail (2.3826.500.181.1.5) X-Spamd-Result: default: False [-4.49 / 15.00]; RBL_SENDERSCORE_REPUT_9(-1.00)[98.137.65.31:from]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.995]; NEURAL_HAM_SHORT(-0.99)[-0.993]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; TO_DN_ALL(0.00)[]; ARC_NA(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; DKIM_TRACE(0.00)[yahoo.com:+]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.31:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.31:from]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_FIVE(0.00)[5] X-Rspamd-Queue-Id: 4ZW8PD0vswz3bpy X-Spamd-Bar: ---- [Correcting a dumb mistaken reference.] On Apr 6, 2025, at 16:43, Mark Millard wrote: > [For the most part the prior history of my notes is not > important so they are mostly omitted this time.] >=20 > It looks like my notes about official bulk package builds > taking longer may be from observations of more than one > distinct issue, one leading to a very rough factor of 2 > and the other not leading to anything like such. >=20 > I'd reported that main-arm64-default was taking very roughly > 2x as long to do its official bulk -a -c (from scratch) > style build. This is what got me to classify the time > increase as rather significant. It was the first thing that > I'd noticed that started my looking around and biased my > interpretation in later looking. >=20 > The recent information for main-arm64-default was: >=20 >> Just for reference for official main-arm64-default bulk -c -a (from >> scratch) builds: >>=20 >>=20 >> p25bf3a3260c7_s680d34896c3 queued 36447 >> and has built 15523 and has 19479 remaining, 134:23:16 so far >> (will have built up to 15523+19479 =3D=3D 35002 when done, if it = finishes) >>=20 >> So: 12 to 13 days (around 300 hrs) as an estimate. >>=20 >>=20 >> The prior longest main-arm64-default official build that completed: >> p02dd5021d6f9_s717adecbbb5 queued 36466 >> and had built 34853 and had 0 remaining, 163:20:35 >>=20 >> So: 6.8 days or so. >>=20 >> Overall: very roughly doubling the overall time when the "for >> real" context does not apply. >=20 > It turns out that the above may well be essentially independent > of the pkg 2.1.0 related time changes. I did a local test of > building my usual aarch64 ports from scratch prior to updating > the ports tree to have pkg 2.1.0 instead on 2.0.6 . I then > updated to use an updated ports tree that has pkg 2.1.0 and > did a test for that context. >=20 > I got nothing remotely like a factor of 2: >=20 > pkg 2.0.6 based /usr/ports/ : > [01:04:57] [release-aarch64-default] [2025-04-06_12h23m09s] = [committing] Time: 01:04:46 > Queued: 264 Inspected: 0 Ignored: 0 Built: 264 Failed: 0 = Skipped: 0 Fetched: 0 Remaining: 0 >=20 > vs. >=20 > pkg 2.1.0 based /usr/ports-alt/ : > [01:07:28] [release-aarch64-alt] [2025-04-06_14h16m21s] [committing] = Time: 01:07:27 > Queued: 265 Inspected: 0 Ignored: 0 Built: 265 Failed: 0 = Skipped: 0 Fetched: 0 Remaining: 0 >=20 >=20 > So: 2 min 31 sec or so difference for overall somewhat over an > hour, i.e., 151 sec or so. That is under 1 sec per package > built. >=20 > At 1 sec or so per package for more like 34853 packages, > that would be more like 9.68 hrs or so added overall. > (Something I should have noticed and reported earlier.) > That may well be more like what is going on for pkg 2.1.0 > related extra time. >=20 > The test was in an apple silicon M4 MAX context under Parallels > on macOS. My build configuration is more biased to allowing > high load averages than the official builds are as well. Also: >=20 > Host OSVERSION: 1500034 > Jail OSVERSION: 1402000 >=20 > So: Host was before 1500035 (which may not be significant). > Also, it is a NO-DEBUG based personal build of the kernel that > had been booted. That build was based on use of > -mcpu=3Dcortex-a76 . The booted world was of an official PkgBase > install. The poudriere jail was also via an official PkgBase > build rather than a personal build: >=20 > # poudriere jail -l > JAILNAME VERSION OSVERSION ARCH METHOD = TIMESTAMP PATH > release-aarch64 14.2-RELEASE-p1 aarch64 pkgbase = 2025-03-12 21:11:39 /usr/local/poudriere/jails/release-aarch64 > . . . >=20 > (Note: "poudriere jail -j release-aarch64 -u" does not seem > to update the "-p1" part of VERSION.) >=20 >=20 > For aarch64, only main-arm64-default ( p25bf3a3260c7_s680d34896c3 ) > has started a from scratch build. The closest aarch64 alternative > is the large build: >=20 > 134arm64-quarterly ( 359bbf7fc5af ) that queued 28018 > and has built 12870 and has 13677 remaining: 92:24:15 >=20 > That suggests 180+ hours overall for less than a > from-scratch build. That is more than the prior > largest time for a completed 134arm64-quarterly > build: 125:58:32 --and by far more than 10 hours. >=20 > 134arm64-quarterly ( 2cbed7722168 ) that queued 36335 > and built 34903 and had 0 remaining: 125:58:32 >=20 > So there being an aarch64 timing issue is not limited to > debug kernel builds, Actually, 134arm64-quarterly also has Host 1500035 : Host OSVERSION: 1500035 Jail OSVERSION: 1304000 and I've no clue if the 1500035 is a debug version vs. not. > although the factor may be somewhat > smaller than 2 for a non-debug kernel and world being > used. =3D=3D=3D Mark Millard marklmi at yahoo.com