From nobody Mon Jan 6 13:05:31 2025 X-Original-To: freebsd-hackers@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 4YRZDT65PBz5kWXB for ; Mon, 06 Jan 2025 13:05:45 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (mailhost.m5p.com [74.104.188.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 (2048 bits) client-digest SHA256) (Client CN "m5p.com", Issuer "R10" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4YRZDS5gKQz4Zkb for ; Mon, 6 Jan 2025 13:05:44 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of george+freebsd@m5p.com designates 74.104.188.4 as permitted sender) smtp.mailfrom=george+freebsd@m5p.com; dmarc=none Received: from [IPV6:2001:470:8ac4::26] (court.m5p.com [IPv6:2001:470:8ac4:0:0:0:0:26]) (authenticated bits=0) by mailhost.m5p.com (8.18.1/8.17.1) with ESMTPSA id 506D5WrU022533 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Mon, 6 Jan 2025 08:05:37 -0500 (EST) (envelope-from george+freebsd@m5p.com) Message-ID: <6c7932c3-bc9a-4e64-a069-ca9619b4a04b@m5p.com> Date: Mon, 6 Jan 2025 08:05:31 -0500 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: FreeBSD Hackers From: George Mitchell Subject: Arcana of the ports build system Autocrypt: addr=george+freebsd@m5p.com; keydata= xjMEZaHDbxYJKwYBBAHaRw8BAQdA2W6oBfS8haXY0/Ft4zS1OTLYfC8EBIADPTgMQdh85C3N KEdlb3JnZSBNaXRjaGVsbCA8Z2VvcmdlK2ZyZWVic2RAbTVwLmNvbT7CmQQTFgoAQRYhBDpv v9n4+UzMLAJ8EZocD3futmd9BQJlocSiAhsDBQkFo5qABQsJCAcCAiICBhUKCQgLAgQWAgMB Ah4HAheAAAoJEJocD3futmd9SxwBAJUi6DNdVhWCZBTv5XGy1g0JgApLWe/3S0M0zz9sn7/L AQCcJcV5k5s2rt9J5C1AUm6XVsuneVvIWXO5j1GKWk0NC844BGWhw28SCisGAQQBl1UBBQEB B0AaFz/6B95RRvjOdLZr5fSdhuIHvwr24H3ePDZSw6wlUwMBCAfCfgQYFgoAJhYhBDpvv9n4 +UzMLAJ8EZocD3futmd9BQJlocNvAhsMBQkFo5qAAAoJEJocD3futmd9RXsBANwRD9RE56F6 /jeZOrujHICLcgPiOt50Y6866v9OUTjUAP9GlC1aopfBpNwuPLJBam7oBaGqvY98VDhzOjoT 7DNbCQ== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------TTguh4tG08R8ewnXHBWvaomd" X-Spam-Status: No, score=0.0 required=10.0 tests=HELO_NO_DOMAIN autolearn=unavailable autolearn_force=no version=4.0.1 X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on mattapan.m5p.com X-Rspamd-Queue-Id: 4YRZDS5gKQz4Zkb X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.28 / 15.00]; SIGNED_PGP(-2.00)[]; MIME_BASE64_TEXT_BOGUS(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; NEURAL_HAM_MEDIUM(-1.00)[-0.995]; R_SPF_ALLOW(-0.20)[+a]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; MIME_BASE64_TEXT(0.10)[]; XM_UA_NO_VERSION(0.01)[]; TAGGED_FROM(0.00)[freebsd]; TO_DN_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; DMARC_NA(0.00)[m5p.com]; RCPT_COUNT_ONE(0.00)[1]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@FreeBSD.org]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; HAS_ATTACHMENT(0.00)[]; R_DKIM_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:701, ipnet:74.104.0.0/16, country:US]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~] This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------TTguh4tG08R8ewnXHBWvaomd Content-Type: multipart/mixed; boundary="------------UKM60rnbpGNfKOXn7lrFUUoJ"; protected-headers="v1" From: George Mitchell To: FreeBSD Hackers Message-ID: <6c7932c3-bc9a-4e64-a069-ca9619b4a04b@m5p.com> Subject: Arcana of the ports build system --------------UKM60rnbpGNfKOXn7lrFUUoJ Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 L3Vzci9wb3J0cy9lZGl0b3JzL2FiaXdvcmQvTWFrZWZpbGUgaW5jbHVkZXMgdGhlc2UgbGlu ZXM6DQoNCkNPTFNFUlZJQ0VfQlJPS0VOPSAgICAgICAgICAgICAgRG9lcyBub3QgYnVpbGQg d2l0aCBhc2lvIGZyb20gc3lzdGVtDQpDT0xTRVJWSUNFX0JVSUxEX0RFUEVORFM9ICAgICAg ICR7TE9DQUxCQVNFfS9pbmNsdWRlL2FzaW8uaHBwOm5ldC9hc2lvDQpDT0xTRVJWSUNFX0xJ Ql9ERVBFTkRTPSAgICAgICAgIGxpYnNvdXAtMi40LnNvOmRldmVsL2xpYnNvdXAgXA0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbGliZ251dGxzLnNvOnNlY3VyaXR5L2du dXRscw0KQ09MU0VSVklDRV9SVU5fREVQRU5EUz0gICAgICAgICAke0xPQ0FMQkFTRX0vaW5j bHVkZS9hc2lvLmhwcDpuZXQvYXNpbw0KQ09MU0VSVklDRV9DT05GSUdVUkVfRU5BQkxFPSAg ICBjb2xsYWItYmFja2VuZC1zZXJ2aWNlDQoNCk5vdyBpbiBmYWN0IEkgaGF2ZSBuZXQvYXNp byBpbnN0YWxsZWQsIGFuZCAvdXNyL2xvY2FsL2luY2x1ZGUvYXNpby5ocHANCmV4aXN0cy4g IEJ1dCBhdHRlbXB0aW5nIHRvIGJ1aWxkIGFiaXdvcmQgc3RvcHMgYW5kIGNvbXBsYWluczoN CkRvZXMgbm90IGJ1aWxkIHdpdGggYXNpbyBmcm9tIHN5c3RlbQ0KQXMgZmFyIGFzIEkgY2Fu IHRlbGwsIG5vIHN1Y2ggdGhpbmcgYXMgImFzaW8gZnJvbSBzeXN0ZW0iIGV2ZW4gZXhpc3Rz Lg0KDQpDYW4gc29tZSBnZW5lcm91cyBzb3VsIGtpbmRseSBzaGVkIHNvbWUgbGlnaHQgb24g d2hhdCdzIGludGVuZGVkIGhlcmU/DQpUaGFua3MsIGFuZCBIYXBweSBOZXcgWWVhciEgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gR2VvcmdlDQo= --------------UKM60rnbpGNfKOXn7lrFUUoJ-- --------------TTguh4tG08R8ewnXHBWvaomd Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wnsEABYIACMWIQQ6b7/Z+PlMzCwCfBGaHA937rZnfQUCZ3vVHAUDAAAAAAAKCRCaHA937rZnfU5M AQDLba9LFteJmVegS5uJ3VnQzVmK24f7aKuWTQEhAISVzAEAy57qJQYwSgbp1lcETfxJBTlK/oCU ujJTOCdL8pWCRwg= =ommW -----END PGP SIGNATURE----- --------------TTguh4tG08R8ewnXHBWvaomd-- From nobody Mon Jan 6 14:00:21 2025 X-Original-To: freebsd-hackers@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 4YRbS30dwtz5kb9C for ; Mon, 06 Jan 2025 14:00:51 +0000 (UTC) (envelope-from 6yearold@gmail.com) Received: from mail-yb1-f182.google.com (mail-yb1-f182.google.com [209.85.219.182]) (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 4YRbS21ZzHz4hGW for ; Mon, 6 Jan 2025 14:00:50 +0000 (UTC) (envelope-from 6yearold@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of 6yearold@gmail.com designates 209.85.219.182 as permitted sender) smtp.mailfrom=6yearold@gmail.com; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=freebsd.org (policy=none) Received: by mail-yb1-f182.google.com with SMTP id 3f1490d57ef6-e461015fbd4so13836746276.2 for ; Mon, 06 Jan 2025 06:00:50 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736172049; x=1736776849; 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=1ThiW1mA1PMj69NVcRHXsacNdbGFJZo/LnJEW30H3So=; b=EEdnf93K2xsAt9Uw65EBkqtkw3jNW+XfUAtw8IU7nNMs+QHPzlXrdPAAu6hLT2UDBS +6AzmdN4vKXGDjoqjGdMs5IJRvwo27+opqTqWXcxpnAD4nIXBz5vDdBLb6bCRLg4Jlpu kcVFl1sJ052bxUttUaVLakkkfGbi+bNwUu+oklMyFkwhJaeeL3ShgBUCauJyaZd1Pvi+ RyVj8n0UtTSlSnoqAHkdaAmSg0FE/Mg4IPV2VM4BgSXA3vEj9YI0xdQDHe9MjJhOImfE 4i26Nd8caYzJjy5xEfrT2sq3ow1HZGqBitxqUg9tj6Hfjy3UVtcsXqqbnKwFDgl8yuIb gRHA== X-Gm-Message-State: AOJu0YymeeAzeWKjrCSvzNPO/7Vh7lMYrykflA9uujhpYwAmE6ytlrhG DgsyDG/A7MXYqKzMPOxEuk7tuinUds4WZvWL6Ma/Ue9n22p8+DSUR6bOBg== X-Gm-Gg: ASbGncuriClkiMWg7Rq8xCKenzh45aga6C5gsWmlXzVKN/w+eB5W/mYPsK4CgzeVh6b kngLR3pkcaeZojuFe1x0TAuNMXsQGJvtvACe/lxH8grtyTRJmLz2HLwaQtz+5+8vKMhtAlObBhZ OvwG7So6cCFRCAIOC4rS+SzlarBgzxodUUJk+zUWxNwe3KJjy01YjdyuZ6i99yqywvdXxQMQzjd zDODIF/e+qLkaOoub5OXlYPnnSl0sQ3tG1hQ/3AQVO72dyrIkXl0xITbQLgEmdYcpUOW0zo98Wy eGdEU5n0STgSXmq+eXKs X-Google-Smtp-Source: AGHT+IEFIbWwZvjSC2FXD9eaTHBsajShhkFJVUz72UbRib6dczuOUnF1SPmD8uBskHghTdFcED4cjw== X-Received: by 2002:a05:690c:4885:b0:6ef:68b9:c97d with SMTP id 00721157ae682-6f3f823b780mr430627757b3.39.1736172048314; Mon, 06 Jan 2025 06:00:48 -0800 (PST) Received: from mail-yb1-f171.google.com (mail-yb1-f171.google.com. [209.85.219.171]) by smtp.gmail.com with ESMTPSA id 00721157ae682-6f3e7895f59sm84246557b3.125.2025.01.06.06.00.47 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 06 Jan 2025 06:00:48 -0800 (PST) Received: by mail-yb1-f171.google.com with SMTP id 3f1490d57ef6-e549be93d5eso3867941276.1 for ; Mon, 06 Jan 2025 06:00:47 -0800 (PST) X-Received: by 2002:a05:690c:6d0e:b0:6ef:5d41:d00 with SMTP id 00721157ae682-6f3f80d5fcbmr364229037b3.5.1736172047648; Mon, 06 Jan 2025 06:00:47 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 References: <6c7932c3-bc9a-4e64-a069-ca9619b4a04b@m5p.com> In-Reply-To: <6c7932c3-bc9a-4e64-a069-ca9619b4a04b@m5p.com> From: Gleb Popov Date: Mon, 6 Jan 2025 17:00:21 +0300 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Arcana of the ports build system To: George Mitchell Cc: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4YRbS21ZzHz4hGW X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.80 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.98)[-0.985]; NEURAL_HAM_MEDIUM(-0.92)[-0.919]; FORGED_SENDER(0.30)[arrowd@freebsd.org,6yearold@gmail.com]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; MIME_GOOD(-0.10)[text/plain]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : SPF not aligned (relaxed), No valid DKIM,none]; RCVD_TLS_LAST(0.00)[]; TO_DN_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; ARC_NA(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; MISSING_XM_UA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_NEQ_ENVFROM(0.00)[arrowd@freebsd.org,6yearold@gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; TAGGED_RCPT(0.00)[freebsd]; R_DKIM_NA(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.219.182:from]; RCVD_IN_DNSWL_NONE(0.00)[209.85.219.182:from,209.85.219.171:received] On Mon, Jan 6, 2025 at 4:05=E2=80=AFPM George Mitchell wrote: > > /usr/ports/editors/abiword/Makefile includes these lines: > > COLSERVICE_BROKEN=3D Does not build with asio from system > COLSERVICE_BUILD_DEPENDS=3D ${LOCALBASE}/include/asio.hpp:net/asio > COLSERVICE_LIB_DEPENDS=3D libsoup-2.4.so:devel/libsoup \ > libgnutls.so:security/gnutls > COLSERVICE_RUN_DEPENDS=3D ${LOCALBASE}/include/asio.hpp:net/asio > COLSERVICE_CONFIGURE_ENABLE=3D collab-backend-service > > Now in fact I have net/asio installed, and /usr/local/include/asio.hpp > exists. But attempting to build abiword stops and complains: > Does not build with asio from system > As far as I can tell, no such thing as "asio from system" even exists. The "system" term here means "installed into system-wide prefix" or in other words "coming from pkg install". The antonym to "system" in this context is "bundled". I presume that Abiword has an option to build with asio that comes together with Abiword itself. From nobody Mon Jan 6 14:18:26 2025 X-Original-To: freebsd-hackers@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 4YRbrV265Rz5kcDP for ; Mon, 06 Jan 2025 14:18:34 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (mailhost.m5p.com [74.104.188.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 (2048 bits) client-digest SHA256) (Client CN "m5p.com", Issuer "R10" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4YRbrT71mfz4kwY; Mon, 6 Jan 2025 14:18:33 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Authentication-Results: mx1.freebsd.org; none Received: from [IPV6:2001:470:8ac4::26] (court.m5p.com [IPv6:2001:470:8ac4:0:0:0:0:26]) (authenticated bits=0) by mailhost.m5p.com (8.18.1/8.17.1) with ESMTPSA id 506EIQYC022808 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 6 Jan 2025 09:18:32 -0500 (EST) (envelope-from george+freebsd@m5p.com) Message-ID: Date: Mon, 6 Jan 2025 09:18:26 -0500 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Arcana of the ports build system To: Gleb Popov Cc: FreeBSD Hackers References: <6c7932c3-bc9a-4e64-a069-ca9619b4a04b@m5p.com> Content-Language: en-US From: George Mitchell Autocrypt: addr=george+freebsd@m5p.com; keydata= xjMEZaHDbxYJKwYBBAHaRw8BAQdA2W6oBfS8haXY0/Ft4zS1OTLYfC8EBIADPTgMQdh85C3N KEdlb3JnZSBNaXRjaGVsbCA8Z2VvcmdlK2ZyZWVic2RAbTVwLmNvbT7CmQQTFgoAQRYhBDpv v9n4+UzMLAJ8EZocD3futmd9BQJlocSiAhsDBQkFo5qABQsJCAcCAiICBhUKCQgLAgQWAgMB Ah4HAheAAAoJEJocD3futmd9SxwBAJUi6DNdVhWCZBTv5XGy1g0JgApLWe/3S0M0zz9sn7/L AQCcJcV5k5s2rt9J5C1AUm6XVsuneVvIWXO5j1GKWk0NC844BGWhw28SCisGAQQBl1UBBQEB B0AaFz/6B95RRvjOdLZr5fSdhuIHvwr24H3ePDZSw6wlUwMBCAfCfgQYFgoAJhYhBDpvv9n4 +UzMLAJ8EZocD3futmd9BQJlocNvAhsMBQkFo5qAAAoJEJocD3futmd9RXsBANwRD9RE56F6 /jeZOrujHICLcgPiOt50Y6866v9OUTjUAP9GlC1aopfBpNwuPLJBam7oBaGqvY98VDhzOjoT 7DNbCQ== In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------dZtaNtQXcvPqPoewA0COE07B" X-Spam-Status: No, score=0.0 required=10.0 tests=HELO_NO_DOMAIN autolearn=unavailable autolearn_force=no version=4.0.1 X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on mattapan.m5p.com X-Rspamd-Queue-Id: 4YRbrT71mfz4kwY X-Spamd-Bar: ---- 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)[freebsd]; ASN(0.00)[asn:701, ipnet:74.104.0.0/16, country:US] This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------dZtaNtQXcvPqPoewA0COE07B Content-Type: multipart/mixed; boundary="------------4p2Mt0LjgxqYE7vfvgX8I0fn"; protected-headers="v1" From: George Mitchell To: Gleb Popov Cc: FreeBSD Hackers Message-ID: Subject: Re: Arcana of the ports build system References: <6c7932c3-bc9a-4e64-a069-ca9619b4a04b@m5p.com> In-Reply-To: --------------4p2Mt0LjgxqYE7vfvgX8I0fn Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMS82LzI1IDA5OjAwLCBHbGViIFBvcG92IHdyb3RlOg0KPiBPbiBNb24sIEphbiA2LCAy MDI1IGF0IDQ6MDXigK9QTSBHZW9yZ2UgTWl0Y2hlbGwgPGdlb3JnZStmcmVlYnNkQG01cC5j b20+IHdyb3RlOg0KPj5bLi4uXQ0KPj4gTm93IGluIGZhY3QgSSBoYXZlIG5ldC9hc2lvIGlu c3RhbGxlZCwgYW5kIC91c3IvbG9jYWwvaW5jbHVkZS9hc2lvLmhwcA0KPj4gZXhpc3RzLiAg QnV0IGF0dGVtcHRpbmcgdG8gYnVpbGQgYWJpd29yZCBzdG9wcyBhbmQgY29tcGxhaW5zOg0K Pj4gRG9lcyBub3QgYnVpbGQgd2l0aCBhc2lvIGZyb20gc3lzdGVtDQo+PiBBcyBmYXIgYXMg SSBjYW4gdGVsbCwgbm8gc3VjaCB0aGluZyBhcyAiYXNpbyBmcm9tIHN5c3RlbSIgZXZlbiBl eGlzdHMuDQo+IA0KPiBUaGUgInN5c3RlbSIgdGVybSBoZXJlIG1lYW5zICJpbnN0YWxsZWQg aW50byBzeXN0ZW0td2lkZSBwcmVmaXgiIG9yIGluDQo+IG90aGVyIHdvcmRzICJjb21pbmcg ZnJvbSBwa2cgaW5zdGFsbCIuDQo+IFRoZSBhbnRvbnltIHRvICJzeXN0ZW0iIGluIHRoaXMg Y29udGV4dCBpcyAiYnVuZGxlZCIuIEkgcHJlc3VtZSB0aGF0DQo+IEFiaXdvcmQgaGFzIGFu IG9wdGlvbiB0byBidWlsZCB3aXRoIGFzaW8gdGhhdCBjb21lcyB0b2dldGhlciB3aXRoDQo+ IEFiaXdvcmQgaXRzZWxmLg0KPiANClNvIC4uLiBkbyBJIHVuZGVyc3RhbmQgdGhhdCB0aGUg d2F5IHRvIHNvbHZlIHRoaXMgcHJvYmxlbSBpcywNCmNvdW50ZXJpbnR1aXRpdmVseS4gdG8g VU5JTlNUQUxMIGFzaW8/PyAgQWNjb3JkaW5nIHRvIHRoZSBwa2cgZGF0YWJhc2UsDQphc2lv IHdhcyBvbmx5IGluc3RhbGxlZCBiZWNhdXNlIGFiaXdvcmQgZGVwZW5kcyBvbiBpdCEhICBJ J2xsIHRyeSBpdCwNCnRob3VnaC4NCg0KR3Vlc3Mgd2hhdCBoYXBwZW5lZC4gIFRoZXJlIHdh cyBubyAiQlJPS0VOIiBjb21wbGFpbnQgdG8gYmVnaW4gd2l0aCwNCmJ1dCB0aGUgZmlyc3Qg dGhpbmcgdGhhdCBoYXBwZW5lZCB3YXMgdGhhdCBidWlsZGluZyBlZGl0b3JzL2FiaXdvcmQN CmNhdXNlZCBuZXQvYXNpbyB0byBiZSBidWlsdCBhbmQgcmVpbnN0YWxsZWQuICBBdCB0aGF0 IHBvaW50LCB0aGUgYnVpbGQNCnJldHVybmVkIHRvIGVkaXRvcnMvYWJpd29yZCwgYW5kIG5v dyBpdCBzYWlkOg0KDQphYml3b3JkLTMuMC41XzExIGlzIG1hcmtlZCBhcyBicm9rZW46IERv ZXMgbm90IGJ1aWxkIHdpdGggYXNpbyBmcm9tDQpzeXN0ZW0gRG9lcyBub3QgYnVpbGQgd2l0 aCBhc2lvIGZyb20gc3lzdGVtLg0KKioqIEVycm9yIGNvZGUgMQ0KDQpTbyBzb21ldGhpbmcg aXMgd3Jvbmcgd2l0aCB0aGUgTWFrZWZpbGUgYXMgaXQgc3RhbmRzLCBhbmQgSSBoYXZlIG5v DQpjbHVlIG9uIGhvdyB0byBmaXggaXQuICBUaGFua3MgZm9yIHlvdXIgYXR0ZW50aW9uLiAg ICAgICAgICAtLSBHZW9yZ2UNCg== --------------4p2Mt0LjgxqYE7vfvgX8I0fn-- --------------dZtaNtQXcvPqPoewA0COE07B Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wnsEABYIACMWIQQ6b7/Z+PlMzCwCfBGaHA937rZnfQUCZ3vmMgUDAAAAAAAKCRCaHA937rZnfe64 AP9hBAIVRJVYliAVA/LKZdS1zO/U0p+PLwc4bdgLO7P9gwD/bgUI0t5h0a3h0yKzhlbbGJVWc6G8 rgvxeDTMwL9fVwc= =ZYPa -----END PGP SIGNATURE----- --------------dZtaNtQXcvPqPoewA0COE07B-- From nobody Mon Jan 6 14:38:49 2025 X-Original-To: freebsd-hackers@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 4YRcJQ0BMBz5kdpf for ; Mon, 06 Jan 2025 14:39:18 +0000 (UTC) (envelope-from 6yearold@gmail.com) Received: from mail-yb1-f169.google.com (mail-yb1-f169.google.com [209.85.219.169]) (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 4YRcJP149Wz4n2F for ; Mon, 6 Jan 2025 14:39:17 +0000 (UTC) (envelope-from 6yearold@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of 6yearold@gmail.com designates 209.85.219.169 as permitted sender) smtp.mailfrom=6yearold@gmail.com; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=freebsd.org (policy=none) Received: by mail-yb1-f169.google.com with SMTP id 3f1490d57ef6-e46ebe19368so18110216276.0 for ; Mon, 06 Jan 2025 06:39:17 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736174356; x=1736779156; 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=CBuXGDz3mG6LrsUOkH3VhJfQc0K8r7Y6KQxTHdMGCkU=; b=mRwOOKMVYhpYqP1xLoxIB9FhfQAi0wgo327cyfvO8pk/8UtDZcVS5UaDit7twFbe2D R01nLQk4RSpSRIflHHg/s/Idu/GkOfeGmMXC6a4TQQ+HykCq7Jukkakyr8P7jqSsc6q2 bb7kShs2+mES9LlVlTZCnrqTSZE/eCmlGY3MPklcNC0l0TDtb5nU11/pIs0WR7ei8K2j QpluFSnSNYWs43mA8RNlg/7Zp8CCX3AAHefGl5GOJGy/z+t1Fm3D1V10SH4mUNFxi1rL Zny9ffZBPJDdDLPcygXcvYgJwr7L5LOZyG86uWLtS47gg6G385xUuL1Tnm0TZ1tONq+3 MWSQ== X-Gm-Message-State: AOJu0YwG1epqOwjmq87kZmuTXhNn92YQL7hG0quiq2O2yt4Pi8uIY03m TwpkcM9dgwv4CtNAmYC09yMVPekVYvYqEC8BmoMoawNPJtjpSx50AeRUNd3h X-Gm-Gg: ASbGncvKGFkpQQPW1ow8JzUWNdzYUunTT/eMpHecYLAB1zSMFAZIYcCumHNDAR4GsHd 7wpOgAHX1hm/+Rp77zEeRomHK9i+wvVJu81G5zB3zXevbY7qrI4zdeq5manb5jm7Xaldvq1T7Pn XR4JFjFaunegLQligxP2bh0S+6Fq2P28BAqh3gnJUfQuXSoNKcQSQ8v8ZB3LIy1aOCAbqkUsdFF qwuY68zjyLtdzo7PJyrXHzHZzResDezwQgZ+3ZKoBxoRtzj3+hLcp6YJ/B/bNn343ibAilhgDAg +6nS2adpTDusyhdTf7+E X-Google-Smtp-Source: AGHT+IHskQUfQKcKO7cD9WlAJswwvGg53aI38XrVHDcI/lWJngfe65JYc45jts8br2PwOvIRHkz2uA== X-Received: by 2002:a05:690c:7007:b0:6ef:6536:bb8c with SMTP id 00721157ae682-6f3f8141cc8mr396803767b3.21.1736174355595; Mon, 06 Jan 2025 06:39:15 -0800 (PST) Received: from mail-yb1-f178.google.com (mail-yb1-f178.google.com. [209.85.219.178]) by smtp.gmail.com with ESMTPSA id 00721157ae682-6f3e74996e1sm84149347b3.63.2025.01.06.06.39.15 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 06 Jan 2025 06:39:15 -0800 (PST) Received: by mail-yb1-f178.google.com with SMTP id 3f1490d57ef6-e3983426f80so19780385276.1 for ; Mon, 06 Jan 2025 06:39:15 -0800 (PST) X-Received: by 2002:a05:690c:6487:b0:6ef:70ae:ca16 with SMTP id 00721157ae682-6f3f823f0camr444629717b3.39.1736174355171; Mon, 06 Jan 2025 06:39:15 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 References: <6c7932c3-bc9a-4e64-a069-ca9619b4a04b@m5p.com> In-Reply-To: From: Gleb Popov Date: Mon, 6 Jan 2025 17:38:49 +0300 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Arcana of the ports build system To: George Mitchell Cc: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4YRcJP149Wz4n2F X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.84 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-0.94)[-0.940]; FORGED_SENDER(0.30)[arrowd@freebsd.org,6yearold@gmail.com]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; MIME_GOOD(-0.10)[text/plain]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : SPF not aligned (relaxed), No valid DKIM,none]; RCVD_TLS_LAST(0.00)[]; TO_DN_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; ARC_NA(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; MISSING_XM_UA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_NEQ_ENVFROM(0.00)[arrowd@freebsd.org,6yearold@gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; TAGGED_RCPT(0.00)[freebsd]; R_DKIM_NA(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.219.169:from]; RCVD_IN_DNSWL_NONE(0.00)[209.85.219.169:from,209.85.219.178:received] On Mon, Jan 6, 2025 at 5:18=E2=80=AFPM George Mitchell wrote: > > On 1/6/25 09:00, Gleb Popov wrote: > > On Mon, Jan 6, 2025 at 4:05=E2=80=AFPM George Mitchell wrote: > >>[...] > >> Now in fact I have net/asio installed, and /usr/local/include/asio.hpp > >> exists. But attempting to build abiword stops and complains: > >> Does not build with asio from system > >> As far as I can tell, no such thing as "asio from system" even exists. > > > > The "system" term here means "installed into system-wide prefix" or in > > other words "coming from pkg install". > > The antonym to "system" in this context is "bundled". I presume that > > Abiword has an option to build with asio that comes together with > > Abiword itself. > > > So ... do I understand that the way to solve this problem is, > counterintuitively. to UNINSTALL asio?? According to the pkg database, > asio was only installed because abiword depends on it!! I'll try it, > though. The COLSERVICE_BUILD_DEPENDS=3D ${LOCALBASE}/include/asio.hpp:net/asio makes Abiword depend on asio if the COLSERVICE option is turned on. > Guess what happened. There was no "BROKEN" complaint to begin with, > but the first thing that happened was that building editors/abiword > caused net/asio to be built and reinstalled. At that point, the build > returned to editors/abiword, and now it said: > > abiword-3.0.5_11 is marked as broken: Does not build with asio from > system Does not build with asio from system. > *** Error code 1 > > So something is wrong with the Makefile as it stands, and I have no > clue on how to fix it. Thanks for your attention. -- George In the same vein, the COLSERVICE_BROKEN=3D Does not build with asio from system works just like plain BROKEN=3D knob, but only when COLSERVICE option is en= abled. You need to turn this option off (or just remove COLSERVICE_BROKEN and see what exactly breaks in this case). From nobody Mon Jan 6 15:13:21 2025 X-Original-To: freebsd-hackers@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 4YRd3t1bp0z5jhx3 for ; Mon, 06 Jan 2025 15:13:30 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (mailhost.m5p.com [74.104.188.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 (2048 bits) client-digest SHA256) (Client CN "m5p.com", Issuer "R10" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4YRd3s5DMBz4rVS; Mon, 6 Jan 2025 15:13:29 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Authentication-Results: mx1.freebsd.org; none Received: from [IPV6:2001:470:8ac4::26] (court.m5p.com [IPv6:2001:470:8ac4:0:0:0:0:26]) (authenticated bits=0) by mailhost.m5p.com (8.18.1/8.17.1) with ESMTPSA id 506FDLAd022976 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 6 Jan 2025 10:13:28 -0500 (EST) (envelope-from george+freebsd@m5p.com) Message-ID: <14496671-00ba-46b6-927a-c69e92044d11@m5p.com> Date: Mon, 6 Jan 2025 10:13:21 -0500 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Arcana of the ports build system To: Gleb Popov Cc: FreeBSD Hackers References: <6c7932c3-bc9a-4e64-a069-ca9619b4a04b@m5p.com> Content-Language: en-US From: George Mitchell Autocrypt: addr=george+freebsd@m5p.com; keydata= xjMEZaHDbxYJKwYBBAHaRw8BAQdA2W6oBfS8haXY0/Ft4zS1OTLYfC8EBIADPTgMQdh85C3N KEdlb3JnZSBNaXRjaGVsbCA8Z2VvcmdlK2ZyZWVic2RAbTVwLmNvbT7CmQQTFgoAQRYhBDpv v9n4+UzMLAJ8EZocD3futmd9BQJlocSiAhsDBQkFo5qABQsJCAcCAiICBhUKCQgLAgQWAgMB Ah4HAheAAAoJEJocD3futmd9SxwBAJUi6DNdVhWCZBTv5XGy1g0JgApLWe/3S0M0zz9sn7/L AQCcJcV5k5s2rt9J5C1AUm6XVsuneVvIWXO5j1GKWk0NC844BGWhw28SCisGAQQBl1UBBQEB B0AaFz/6B95RRvjOdLZr5fSdhuIHvwr24H3ePDZSw6wlUwMBCAfCfgQYFgoAJhYhBDpvv9n4 +UzMLAJ8EZocD3futmd9BQJlocNvAhsMBQkFo5qAAAoJEJocD3futmd9RXsBANwRD9RE56F6 /jeZOrujHICLcgPiOt50Y6866v9OUTjUAP9GlC1aopfBpNwuPLJBam7oBaGqvY98VDhzOjoT 7DNbCQ== In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------m0hu0S5fXYmwG8DBdhYeqUGW" X-Spam-Status: No, score=0.0 required=10.0 tests=HELO_NO_DOMAIN autolearn=unavailable autolearn_force=no version=4.0.1 X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on mattapan.m5p.com X-Rspamd-Queue-Id: 4YRd3s5DMBz4rVS X-Spamd-Bar: ---- 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)[freebsd]; ASN(0.00)[asn:701, ipnet:74.104.0.0/16, country:US] This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------m0hu0S5fXYmwG8DBdhYeqUGW Content-Type: multipart/mixed; boundary="------------obi4jAqopPDtwLXd1NSYvri3"; protected-headers="v1" From: George Mitchell To: Gleb Popov Cc: FreeBSD Hackers Message-ID: <14496671-00ba-46b6-927a-c69e92044d11@m5p.com> Subject: Re: Arcana of the ports build system References: <6c7932c3-bc9a-4e64-a069-ca9619b4a04b@m5p.com> In-Reply-To: --------------obi4jAqopPDtwLXd1NSYvri3 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMS82LzI1IDA5OjM4LCBHbGViIFBvcG92IHdyb3RlOg0KPiBbLi4uXQ0KPiBJbiB0aGUg c2FtZSB2ZWluLCB0aGUNCj4gDQo+IENPTFNFUlZJQ0VfQlJPS0VOPSAgICAgICAgICAgICAg RG9lcyBub3QgYnVpbGQgd2l0aCBhc2lvIGZyb20gc3lzdGVtDQo+IA0KPiB3b3JrcyBqdXN0 IGxpa2UgcGxhaW4gQlJPS0VOPSBrbm9iLCBidXQgb25seSB3aGVuIENPTFNFUlZJQ0Ugb3B0 aW9uIGlzIGVuYWJsZWQuDQo+IA0KPiBZb3UgbmVlZCB0byB0dXJuIHRoaXMgb3B0aW9uIG9m ZiAob3IganVzdCByZW1vdmUgQ09MU0VSVklDRV9CUk9LRU4gYW5kDQo+IHNlZSB3aGF0IGV4 YWN0bHkgYnJlYWtzIGluIHRoaXMgY2FzZSkuDQo+IA0KDQpBaCEgIEl0IGlzIHNvIG9idmlv dXMgaW4gdGhlIGxpZ2h0IG9mIHVuZGVyc3RhbmRpbmcuICBJIHRoYW5rIHlvdSBmb3INCmV4 cGxhaW5pbmcgaXQgdG8gbWUhICBJIGRvbid0IHJlbWVtYmVyIGhhdmluZyBzZXQgYW55IGNv bGxhYm9yYXRpb24NCm9wdGlvbnMgd2hlbiBJIGZpcnN0IGluc3RhbGxlZCB0aGUgcGFja2Fn ZSwgYW5kIEknbSBzdXJwcmlzZWQgdGhhdCBteQ0Kb3B0aW9ucyBhcmUgYW55IGRpZmZlcmVu dCBmcm9tIHRoZSBkZWZhdWx0cy4gIEJ1dCBpdCB3YXMgYSBsb25nIHRpbWUNCmJhY2sgdGhh dCBJIGZpcnN0IGluc3RhbGxlZCB0aGUgcGFja2FnZS4NCg0KSSBncmVhdGx5IGFwcHJlY2lh dGUgeW91ciBncmFjaW91cyBhc3Npc3RhbmNlLiAgICAgICAgICAgICAgIC0tIEdlb3JnZQ0K --------------obi4jAqopPDtwLXd1NSYvri3-- --------------m0hu0S5fXYmwG8DBdhYeqUGW Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wnsEABYIACMWIQQ6b7/Z+PlMzCwCfBGaHA937rZnfQUCZ3vzEQUDAAAAAAAKCRCaHA937rZnfcWt AP99u0akxc30tDXKXbjRUDitzAK48FPXtVWCjmTDKXrE0gD/SNa13VwqM6ac5ZHoB0oCTV/eJWIL ixb34VFZqb6ReAM= =RDWp -----END PGP SIGNATURE----- --------------m0hu0S5fXYmwG8DBdhYeqUGW-- From nobody Wed Jan 8 21:31:16 2025 X-Original-To: freebsd-hackers@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 4YT1M04B2Wz5k0tV for ; Wed, 08 Jan 2025 21:31:24 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (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 4YT1Lz2vvwz4XLS for ; Wed, 8 Jan 2025 21:31:23 +0000 (UTC) (envelope-from markjdb@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b="KpH/2iOg"; spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::d32 as permitted sender) smtp.mailfrom=markjdb@gmail.com; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=freebsd.org (policy=none) Received: by mail-io1-xd32.google.com with SMTP id ca18e2360f4ac-844e12f702dso7370539f.3 for ; Wed, 08 Jan 2025 13:31:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736371881; x=1736976681; darn=freebsd.org; h=content-disposition:mime-version:message-id:subject:to:from:date :sender:from:to:cc:subject:date:message-id:reply-to; bh=qSMBhTCfXvDIMjFvxAU6aslAJ5IzJa/QmF49Mx1EiLc=; b=KpH/2iOglyRNOZWTYVAH9MFzCPvH7lnCrU7yc00XtdOGm9SUtw9ogVSprnrKfh654C ghDXF9QAyZJ6zsIzamY4JNWIcgommUOoiHfgFCrhwBm9P+7lhdb+F2QPKvjFJwQW+N40 vtyXRjXRUpA5eGBuRDYyE7JE52nw6VzPN0W2cIfURSpfOkm23hPJMN9LSFC6PEIfsRdq CEHDTKqiNp3F5lwED7fAtkeOTNx9K+Hmiibz4QKcIVcVP9SnQLwN1l9dzmRA5LTICcye IschJHvdq1E5BWgWoZ5DqO9mHXijQeRyd7KuPoZhMyBAqpeAhOHh9ZK0IBVuiEZ5lFuV 7xCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736371881; x=1736976681; h=content-disposition:mime-version:message-id:subject:to:from:date :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=qSMBhTCfXvDIMjFvxAU6aslAJ5IzJa/QmF49Mx1EiLc=; b=mRTtYh5K6YqX67poKKr6dZC+Ej8mxAt8HwVesjRFr/sReFCKA2qapJNAibuiyPiAPG IF4AyxNlHfEFq8nV0XUmp7naCe7N544PO6nP65+0NIacYSv5z6BA8VGnwmmgX0urZ7BT sJc5vbbQnHtEkE0ExSXyrdPljwAv6+bYmyJQvjdDZYtv2iBQ21TAPRLh+klq6g3eATMi M+SC9FOIFlKFMWeE0/+6BASey4NDbWIAD38uZ981WKqxwHQ72q7S8pk5mDNgLjZapNL8 OkKkaHOCIj4wb52/yAUjNzmfM6JGxVULioruOPFrLdwMYB2Ywxf/XIVp5DijL/hTkpgR CXcA== X-Gm-Message-State: AOJu0YyXT+SV+edjKohdAI/7adVc5UxCdpHbInAk0ziOkLw8mguu45Wn sMqMoWP3wS0KTQZJY5cFDgejQfqnx7PKELmTkU3rer8nz2ZWx8bft7hj3A== X-Gm-Gg: ASbGncutkcv2Ft5z/3wU75BLl65FrY435ITClDTXTCcQ3y7R4JaWLdqWLhKfxQ3SbAV OY7KzOL7wVv446FMsNomsnQAV3a4IjeWwni6TGjPdnZeEfuS/76uTozds6zUF6pBEROWI2GjpgI 9m4DxVHeqBgspxd6MraOWuq3T547zOoC7/P8PgTkoiDNbkyBKyFNUaIY1ofeCX5Z+BOJQORh2m/ 9uGdsmMxde9QiIs+HOAf3kVlsjmzJZke2mLb2PK4Xl7hfF5N1ZeX1QRIuLJkUwvl9c/MQQ= X-Google-Smtp-Source: AGHT+IFINarUfpPBp+BQ0fvlmUu2inaZKD1dGwnFWvovqUWFKYgLa/bn42cN1ibsRdRJm7/5e8EBeg== X-Received: by 2002:a05:6602:381b:b0:835:45f9:c2ee with SMTP id ca18e2360f4ac-84ce00f6671mr463521439f.4.1736371881211; Wed, 08 Jan 2025 13:31:21 -0800 (PST) Received: from nuc (192-0-220-237.cpe.teksavvy.com. [192.0.220.237]) by smtp.gmail.com with ESMTPSA id ca18e2360f4ac-84d4fb3f68bsm318939f.20.2025.01.08.13.31.18 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 08 Jan 2025 13:31:19 -0800 (PST) Date: Wed, 8 Jan 2025 16:31:16 -0500 From: Mark Johnston To: freebsd-hackers@freebsd.org Subject: widening ticks Message-ID: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Rspamd-Queue-Id: 4YT1Lz2vvwz4XLS X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.60 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.996]; MID_RHS_NOT_FQDN(0.50)[]; FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : SPF not aligned (relaxed), DKIM not aligned (relaxed),none]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MISSING_XM_UA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; TO_DN_NONE(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com]; DKIM_TRACE(0.00)[gmail.com:+]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DOM_EQ_FROM_DOM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::d32:from] The global "ticks" variable counts hardclock ticks, it's widely used in the kernel for low-precision timekeeping. The linuxkpi provides a very similar variable, "jiffies", but there's an incompatibility: the former is a signed int and the latter is an unsigned long. It's not particularly easy to paper over this difference, which has been responsible for some nasty bugs, and modifying drivers to store the jiffies value in a signed int is error-prone and a maintenance burden that the linuxkpi is supposed to avoid. It would be nice to provide a compatible implementation of jiffies. I can see a few approaches: - Define a 64-bit ticks variable, say ticks64, and make hardclock() update both ticks and ticks64. Then #define jiffies ticks64 on 64-bit platforms. This is the simplest to implement, but it adds extra work to hardclock() and is somewhat ugly. - Make ticks an int64_t or a long and convert our native code accordingly. This is cleaner but requires a lot of auditing to avoid introducing bugs, though perhaps some code could be left unmodified, implicitly truncating the value to an int. For example I think sched_pctcpu_update() is fine. I've gotten an amd64 kernel to compile and boot with this change, but it's hard to be confident in it. This approach also has the potential downside of bloating structures that store a ticks value, and it can't be MFCed. - Introduce a 64-bit ticks variable, ticks64, and #define ticks ((int)ticks64). This requires renaming any struct fields and local vars named "ticks", of which there's a decent number, but that can be done fairly mechanically. Is there another solution which avoids these pitfalls? If not, should we go ahead with one of these approaches? If so, which one? From nobody Wed Jan 8 21:51:31 2025 X-Original-To: freebsd-hackers@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 4YT1pS49tsz5k3Bq for ; Wed, 08 Jan 2025 21:51:44 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pl1-x62e.google.com (mail-pl1-x62e.google.com [IPv6:2607:f8b0:4864:20::62e]) (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 4YT1pS2301z4bZF for ; Wed, 8 Jan 2025 21:51:44 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pl1-x62e.google.com with SMTP id d9443c01a7336-2164b662090so3287905ad.1 for ; Wed, 08 Jan 2025 13:51:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1736373103; x=1736977903; 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=DTke1ASZBzG/vUe6AxhJXhFq/d39MXIdhiS7IuWYJXw=; b=JM6Iwpuxi+SaJG3c604ykIEn+GQpb9utZodn05HnzCAQPfpF35IuLl1k31mkXiyNaS hjdLv3k7NQgeMnDhoVMHjhEUjpdUc/tvKLoQHxvwqo9yLKB7JjbvfduL3Jbj/gCV3Sn6 1/qhIWTnf4GyDml+a/lS75n/CzGGfIuWt40W98q8NvdjMab9iMi1o0ZmLzLzMVut1x9s kQsXvN8xBQYWKYP51MOF900ujub4MVn7E2g/orynTY+vS03gv5hxyvqkQ614QDDNEclc mcNfAOMfNXpAshB7Yc6B3qBy6E+6rjD06KcGwEmgL9K3LZ4ZCSuHTo4+mrDuXHtvur1+ 8Wkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736373103; x=1736977903; 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=DTke1ASZBzG/vUe6AxhJXhFq/d39MXIdhiS7IuWYJXw=; b=EpSloPrzbvfCd1gRwoCCh1UIZ2NZ5iI+d3R8FJKRReaDHjcYq94Fs6ldjubVDcVdx7 +GYdY1G1nelGzBr6jqdkcwtvbD9vlXihCAZCRY0pAxjbEpmGNdlIKV/tkVfWB/WC6MBs As8x1y3NLhuMWeaonzzF/zheqG0xEFIU/Q1oa+wvHqDtjZez2ysUnnY/YVcE/dDleqyF Jpcf6vFg4mvupjHKfbDdacXY06rD9PCdwvWheq5sW+X3ZUgW5BGFXm2+aygMDZiXY2Ok gcpoKPD2s736OZ7SvqhAA9OMCAPiAMe4g97Zzg5haEoNAAttGjm97xDHRDAPklRs0+pP haYA== X-Gm-Message-State: AOJu0Yx9+oNLW30xW111XNix8+kFxdykHyyg/KipvfVLgTpcSQtZMNS8 YPmKE+e5tIBVBRxyqLdnWhIboX500mwsYBR2AUxGks1Isk/bFYd0uJLzUWWq1FH2j+uleP6hfhc 9CtoUmQMHawXDXGHMI/RTZLaW+RNuVN0xZkJLNAZfwNslkPcK6ddFAg== X-Gm-Gg: ASbGncu6MHcjE1MObComN/KJvkR00GL1ebOQT4NEKmfXqLWpI1OImwxfLVcNTqJ7wQU ubKl//wimF+ifqesSARUQjAqHYM699G5i0FLMRQ== X-Google-Smtp-Source: AGHT+IH1/esAq2DBsM8SUEzSv2bXY5rdjfBxKfURPsG5zQiIg8r3ZFi++72f0KYLlFbyi5LO+5zam3Kmi5LMAh1k8vc= X-Received: by 2002:a05:6a00:1942:b0:725:d956:aa6f with SMTP id d2e1a72fcca58-72d21f7f5a6mr6829915b3a.5.1736373102610; Wed, 08 Jan 2025 13:51:42 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Wed, 8 Jan 2025 14:51:31 -0700 X-Gm-Features: AbW1kvZbIYwqEyCdfqkbkyZXye9Ek2kobRSu0YMM9x8gi-142cGHoR4vJzhW8iQ Message-ID: Subject: Re: widening ticks To: Mark Johnston Cc: freebsd-hackers@freebsd.org Content-Type: multipart/alternative; boundary="000000000000faa563062b38ddd8" X-Rspamd-Queue-Id: 4YT1pS2301z4bZF X-Spamd-Bar: ---- 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] --000000000000faa563062b38ddd8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jan 8, 2025 at 2:31=E2=80=AFPM Mark Johnston wr= ote: > The global "ticks" variable counts hardclock ticks, it's widely used in > the kernel for low-precision timekeeping. The linuxkpi provides a very > similar variable, "jiffies", but there's an incompatibility: the former > is a signed int and the latter is an unsigned long. It's not > particularly easy to paper over this difference, which has been > responsible for some nasty bugs, and modifying drivers to store the > jiffies value in a signed int is error-prone and a maintenance burden > that the linuxkpi is supposed to avoid. > > It would be nice to provide a compatible implementation of jiffies. I > can see a few approaches: > - Define a 64-bit ticks variable, say ticks64, and make hardclock() > update both ticks and ticks64. Then #define jiffies ticks64 on 64-bit > platforms. This is the simplest to implement, but it adds extra work > to hardclock() and is somewhat ugly. > - Make ticks an int64_t or a long and convert our native code > accordingly. This is cleaner but requires a lot of auditing to avoid > introducing bugs, though perhaps some code could be left unmodified, > implicitly truncating the value to an int. For example I think > sched_pctcpu_update() is fine. I've gotten an amd64 kernel to compile > and boot with this change, but it's hard to be confident in it. This > approach also has the potential downside of bloating structures that > store a ticks value, and it can't be MFCed. > - Introduce a 64-bit ticks variable, ticks64, and > #define ticks ((int)ticks64). This requires renaming any struct > fields and local vars named "ticks", of which there's a decent number, > but that can be done fairly mechanically. > > Is there another solution which avoids these pitfalls? If not, should > we go ahead with one of these approaches? If so, which one? > So solution (1) is MFC-able, I think, so I like it. (2) Isn't, but is likely a better long-term solution. (3) is a non-starter since ticks is too common a name to #define. I could easily see a situation where we do (1) and then convert all current users of ticks to be ticks64. This could proceed one at a time with as much haste or caution as we need. Once we convert all of them over, we could delete ticks and then there'd be no extra work in hardclock. This too would be MFC-able. sys/net/iflib.c: uint64_t this_tick =3D ticks; sys/netinet/tcp_subr.c: < (u_int)ticks))) { look fun! We also shadow it in a lot of places. The TCP stack uses it a lot with a bunch of different variables, struct entries, etc, including RACK and BBR. The 802.11 stack uses it a bunch. As to a bunch of drivers, sometimes shadowing other times not. It would be a lot to audit all this, so I think having the new API in place might be better, and incrementally converting / removing the shadowing (even if it isn't completely in scoe, using ticks as a local variable is begging for trouble)= . Warner Also I see both jiffies and jiffies_64 defined. Does that matter at all? --000000000000faa563062b38ddd8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Jan 8, = 2025 at 2:31=E2=80=AFPM Mark Johnston <markj@freebsd.org> wrote:
The global "ticks" variable counts hardclock= ticks, it's widely used in
the kernel for low-precision timekeeping.=C2=A0 The linuxkpi provides a ver= y
similar variable, "jiffies", but there's an incompatibility: = the former
is a signed int and the latter is an unsigned long.=C2=A0 It's not
particularly easy to paper over this difference, which has been
responsible for some nasty bugs, and modifying drivers to store the
jiffies value in a signed int is error-prone and a maintenance burden
that the linuxkpi is supposed to avoid.

It would be nice to provide a compatible implementation of jiffies.=C2=A0 I=
can see a few approaches:
- Define a 64-bit ticks variable, say ticks64, and make hardclock()
=C2=A0 update both ticks and ticks64.=C2=A0 Then #define jiffies ticks64 on= 64-bit
=C2=A0 platforms.=C2=A0 This is the simplest to implement, but it adds extr= a work
=C2=A0 to hardclock() and is somewhat ugly.
- Make ticks an int64_t or a long and convert our native code
=C2=A0 accordingly.=C2=A0 This is cleaner but requires a lot of auditing to= avoid
=C2=A0 introducing bugs, though perhaps some code could be left unmodified,=
=C2=A0 implicitly truncating the value to an int.=C2=A0 For example I think=
=C2=A0 sched_pctcpu_update() is fine.=C2=A0 I've gotten an amd64 kernel= to compile
=C2=A0 and boot with this change, but it's hard to be confident in it.= =C2=A0 This
=C2=A0 approach also has the potential downside of bloating structures that=
=C2=A0 store a ticks value, and it can't be MFCed.
- Introduce a 64-bit ticks variable, ticks64, and
=C2=A0 #define ticks ((int)ticks64).=C2=A0 This requires renaming any struc= t
=C2=A0 fields and local vars named "ticks", of which there's = a decent number,
=C2=A0 but that can be done fairly mechanically.

Is there another solution which avoids these pitfalls?=C2=A0 If not, should=
we go ahead with one of these approaches?=C2=A0 If so, which one?

So solution (1) is MFC-able, I think, so I like = it.
(2) Isn't, but is likely a better long-term solution.
(3) is a non-starter since ticks is too common a name to #define.

I could easily see a situation where we do (1) and t= hen convert all current
users of ticks to be ticks64. This could = proceed one at a time with as much
haste or caution as we need. O= nce we convert all of them over, we could
delete ticks and then t= here'd be no extra work in hardclock. This too would
be MFC-a= ble.

sys/net/iflib.c: uint64_t this_tick =3D ticks= ;
sys/netinet/tcp_subr.c: =C2=A0 =C2=A0 =C2=A0 =C2=A0 < (u_int= )ticks))) {

look fun! We also shadow it in a lot o= f places. The TCP stack uses it a lot
with a bunch of different v= ariables, struct entries, etc, including RACK and BBR.
The 802.11= stack uses it a bunch.=C2=A0 As to a bunch of drivers, sometimes shadowing=
other times not.

It would be a lot to a= udit all this, so I think having the new API in place might be
be= tter, and incrementally converting / removing the shadowing (even if it isn= 't
completely in scoe, using ticks as a local variable is beg= ging for trouble).

Warner

Also I see both jiffies and jiffies_64 defined. Does that matter at all?

--000000000000faa563062b38ddd8-- From nobody Wed Jan 8 22:18:48 2025 X-Original-To: freebsd-hackers@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 4YT2Py12rfz5k5T9 for ; Wed, 08 Jan 2025 22:19:02 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4YT2Px3zWRz4fyH; Wed, 8 Jan 2025 22:19:01 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.18.1/8.18.1) with ESMTP id 508MImis070599; Thu, 9 Jan 2025 00:18:51 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 508MImis070599 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 508MImcb070598; Thu, 9 Jan 2025 00:18:48 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 9 Jan 2025 00:18:48 +0200 From: Konstantin Belousov To: Mark Johnston Cc: freebsd-hackers@freebsd.org Subject: Re: widening ticks Message-ID: References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=4.0.1 X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on tom.home X-Rspamd-Queue-Id: 4YT2Px3zWRz4fyH X-Spamd-Bar: ---- 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:6939, ipnet:2001:470::/32, country:US] On Wed, Jan 08, 2025 at 04:31:16PM -0500, Mark Johnston wrote: > The global "ticks" variable counts hardclock ticks, it's widely used in > the kernel for low-precision timekeeping. The linuxkpi provides a very > similar variable, "jiffies", but there's an incompatibility: the former > is a signed int and the latter is an unsigned long. It's not > particularly easy to paper over this difference, which has been > responsible for some nasty bugs, and modifying drivers to store the > jiffies value in a signed int is error-prone and a maintenance burden > that the linuxkpi is supposed to avoid. > > It would be nice to provide a compatible implementation of jiffies. I > can see a few approaches: > - Define a 64-bit ticks variable, say ticks64, and make hardclock() > update both ticks and ticks64. Then #define jiffies ticks64 on 64-bit > platforms. This is the simplest to implement, but it adds extra work > to hardclock() and is somewhat ugly. > - Make ticks an int64_t or a long and convert our native code > accordingly. This is cleaner but requires a lot of auditing to avoid > introducing bugs, though perhaps some code could be left unmodified, > implicitly truncating the value to an int. For example I think > sched_pctcpu_update() is fine. I've gotten an amd64 kernel to compile > and boot with this change, but it's hard to be confident in it. This > approach also has the potential downside of bloating structures that > store a ticks value, and it can't be MFCed. > - Introduce a 64-bit ticks variable, ticks64, and > #define ticks ((int)ticks64). This requires renaming any struct > fields and local vars named "ticks", of which there's a decent number, > but that can be done fairly mechanically. > > Is there another solution which avoids these pitfalls? If not, should > we go ahead with one of these approaches? If so, which one? You cannot do this in C, but can in asm: .data .globl ticksl, ticks .type ticksl, @object .type ticks, @object ticksl: .quad .size ticksl, 8 ticks =ticksl /* for little-endian */ /* ticks =ticksl + 4 for big-endian */ .size ticks, 4 Then update only ticksl in the hardclock(). From nobody Wed Jan 8 22:20:19 2025 X-Original-To: freebsd-hackers@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 4YT2RX6FzCz5k5Gm for ; Wed, 08 Jan 2025 22:20:24 +0000 (UTC) (envelope-from markjdb@gmail.com) 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 4YT2RX3cR8z4gfg for ; Wed, 8 Jan 2025 22:20:24 +0000 (UTC) (envelope-from markjdb@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-io1-xd34.google.com with SMTP id ca18e2360f4ac-844eac51429so19051139f.2 for ; Wed, 08 Jan 2025 14:20:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736374823; x=1736979623; darn=freebsd.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:sender :from:to:cc:subject:date:message-id:reply-to; bh=4gH9jF7spXB+iY0BRsgo/evvPSo+p8EgbF3ACWuDLq8=; b=WbuOTg3hUF9xjEanBk/zHSsUgasdEevoEZhYfjD32vpPZGSiMFOFKEoc1GhoEfycem agQ0NS+msHp6LHI1rSe/Erz9/ZcjOMzb+wfeHz/ayfvu6TjKjR820dBkHOQ4XSmHazsi OnKAl18ku7+TbobkidgFm+C+uavtYtf/8/IhdUvwzzlap+sGbJCwojgOxqqnUMbO8d3q ivDOfYjjO8hKSBjhSkrY9OYBo+QuIO64KF9gjywkFkiJVEJm1+U0C5DmyM004Y0xAkKC otyo7tz0cfSqxhZ9+r1fUl3PXDZrJtlPQY3/YrJXgcA3IutUKm9OFGhKOAcMkgmGA/AZ mBnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736374823; x=1736979623; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:sender :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=4gH9jF7spXB+iY0BRsgo/evvPSo+p8EgbF3ACWuDLq8=; b=sPJg9YK1vaKpjHNKNcTJ+aKzfKk7Vk1SyipJcLw0mtOf7Rh/X675+59ZQq6Eua2Iqm Nxk2PtDJ3lLXmK31z3d6R7D/l6NI4EZrG1bHhOlOgQdtXS70JvjVm+vFqdeCu8/Ltr8E 0a6iGC6t4aVPbcjpKU7lZHz+V9t2xkqMApcpgwMpExk331kByqgIB4y5YFA0Oy62JS2i 6mOT3sLiyrxoOxqElyVoAKmTduzJQ819br2SsFVJXz55hOPU58Wk3bxoa/iw3pnkr9cS azi4b1wrVGqWPuPT5+vGOU88iWqMTTEDuQtm939DoNRyaSsjUVIjfZncOQWXPn7/MERS E9wQ== X-Gm-Message-State: AOJu0YyPpdOXfJkZKWa/AKaNIxPaIHIEeWu7exnIVH/Myly08Mu9VSE4 bHBnuzib/fLsyC6UePKarLmRIe1WLL7OCbLcY2SWktBjqDCqAJpBkVUcgg== X-Gm-Gg: ASbGnctdHWJ2ZHPl/nUHDhbgnKBFUtpp0Q456kImpePZrlDcLb33mhyL8c1ND0b8SnD XxNjzmQ6/H3l2fELp44GaildDqLFEWCOftPeBUVPa+u7VJWRJd5h/h+JQOd/I1KRn/g/0dOiX4R c/tvN2+JjOk4LOFOqKBqBxEi7Ix7yJaNnoE50MHSMEvRrOe9hM7WX/EUgWQFDTKi8d4silLXPTk jBGrd0+h6syo3sYhFB6pL+F5lZnXCPZjOZWHTuw5Wg7xrvYJC3OjW72Io+lACrGicN+0HA= X-Google-Smtp-Source: AGHT+IEa46/T+9O9G0GiO3p8KlE0ctnUhgJATGrdPS3/JStEtEYqBucc9dxagqAGKOw0Hz0HYTjvZQ== X-Received: by 2002:a92:cda6:0:b0:3a7:70a4:6877 with SMTP id e9e14a558f8ab-3ce3a87a690mr35967105ab.7.1736374823535; Wed, 08 Jan 2025 14:20:23 -0800 (PST) Received: from nuc (192-0-220-237.cpe.teksavvy.com. [192.0.220.237]) by smtp.gmail.com with ESMTPSA id e9e14a558f8ab-3ce4af5649csm79875ab.64.2025.01.08.14.20.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 08 Jan 2025 14:20:22 -0800 (PST) Date: Wed, 8 Jan 2025 17:20:19 -0500 From: Mark Johnston To: Warner Losh Cc: freebsd-hackers@freebsd.org Subject: Re: widening ticks Message-ID: References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Queue-Id: 4YT2RX3cR8z4gfg X-Spamd-Bar: ---- 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] On Wed, Jan 08, 2025 at 02:51:31PM -0700, Warner Losh wrote: > On Wed, Jan 8, 2025 at 2:31 PM Mark Johnston wrote: > > > The global "ticks" variable counts hardclock ticks, it's widely used in > > the kernel for low-precision timekeeping. The linuxkpi provides a very > > similar variable, "jiffies", but there's an incompatibility: the former > > is a signed int and the latter is an unsigned long. It's not > > particularly easy to paper over this difference, which has been > > responsible for some nasty bugs, and modifying drivers to store the > > jiffies value in a signed int is error-prone and a maintenance burden > > that the linuxkpi is supposed to avoid. > > > > It would be nice to provide a compatible implementation of jiffies. I > > can see a few approaches: > > - Define a 64-bit ticks variable, say ticks64, and make hardclock() > > update both ticks and ticks64. Then #define jiffies ticks64 on 64-bit > > platforms. This is the simplest to implement, but it adds extra work > > to hardclock() and is somewhat ugly. > > - Make ticks an int64_t or a long and convert our native code > > accordingly. This is cleaner but requires a lot of auditing to avoid > > introducing bugs, though perhaps some code could be left unmodified, > > implicitly truncating the value to an int. For example I think > > sched_pctcpu_update() is fine. I've gotten an amd64 kernel to compile > > and boot with this change, but it's hard to be confident in it. This > > approach also has the potential downside of bloating structures that > > store a ticks value, and it can't be MFCed. > > - Introduce a 64-bit ticks variable, ticks64, and > > #define ticks ((int)ticks64). This requires renaming any struct > > fields and local vars named "ticks", of which there's a decent number, > > but that can be done fairly mechanically. > > > > Is there another solution which avoids these pitfalls? If not, should > > we go ahead with one of these approaches? If so, which one? > > > > So solution (1) is MFC-able, I think, so I like it. > (2) Isn't, but is likely a better long-term solution. > (3) is a non-starter since ticks is too common a name to #define. Why is that a non-starter? This is just in the kernel, and as you note below, shadowing ticks isn't a great idea anyway. (I don't really want to go down this path in any case, but I'm wondering if I misunderstood something.) > I could easily see a situation where we do (1) and then convert all current > users of ticks to be ticks64. This could proceed one at a time with as much > haste or caution as we need. Once we convert all of them over, we could > delete ticks and then there'd be no extra work in hardclock. This too would > be MFC-able. > > sys/net/iflib.c: uint64_t this_tick = ticks; > sys/netinet/tcp_subr.c: < (u_int)ticks))) { > > look fun! We also shadow it in a lot of places. The TCP stack uses it a lot > with a bunch of different variables, struct entries, etc, including RACK > and BBR. > The 802.11 stack uses it a bunch. As to a bunch of drivers, sometimes > shadowing > other times not. > > It would be a lot to audit all this, so I think having the new API in place > might be > better, and incrementally converting / removing the shadowing (even if it > isn't > completely in scoe, using ticks as a local variable is begging for trouble). Yeah, looking some more, I think having a flag day will make this too painful. So then I guess the question is, do we provide an int64_t ticks64 or a long ticksl? Do we have any 32-bit platforms where a 64-bit cmpset in hardclock() would be a problem? > Warner > > Also I see both jiffies and jiffies_64 defined. Does that matter at all? They differ only on 32-bit systems I believe. On such systems there is a 64-bit tick counter, jiffies_64, but it might not be atomic. From nobody Wed Jan 8 22:22:26 2025 X-Original-To: freebsd-hackers@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 4YT2Tz56BTz5k5Yy for ; Wed, 08 Jan 2025 22:22:31 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-il1-x136.google.com (mail-il1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4YT2Ty6LLDz4hjs for ; Wed, 8 Jan 2025 22:22:30 +0000 (UTC) (envelope-from markjdb@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-il1-x136.google.com with SMTP id e9e14a558f8ab-3ab29214f45so774545ab.0 for ; Wed, 08 Jan 2025 14:22:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736374949; x=1736979749; darn=freebsd.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:from:to:cc:subject:date:message-id :reply-to; bh=98uZ3nSChqgR2S47H+qJ0IciOZvzmRPNf72LkvCvQuo=; b=O/d2uxk+ImMYLGDfud/I34Vd+ffGpHgDFWAnAv1cPEriuiY/VAyEBLwQyiHSHCq9AL 9f3WcoK3ggqHrP+NYEHq9B/z1fvXaJVoxYtIeQmi59NNv3AHF0nsaegZ7+1LPuvHKFiu 5Lk+WeUBXEEQkLThTEDg/nGTNharnRNkhnnQvigxbD3ZqjUrz/wMvPLvggeh/GVJuQVw 4FMDE17SCwBz4qbwmOxNdvDrmR4PvEu1Exm59wv+K7Nt3DXkO+UcD8foISe/x62hnQ68 TrftwRChmxNnXbN3wJ1AlYIckgn2mWwAnufUuWdPC/Aeg+ktmjieMRvGrzF9NkfqatwX SZIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736374949; x=1736979749; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=98uZ3nSChqgR2S47H+qJ0IciOZvzmRPNf72LkvCvQuo=; b=mKear3WX6ozhqZE0kyEfTge1Wc+XPZsTzjKI35E++WCsTr7NGI7hgdoZQrpXHRAhwt nDqKf4kxU8pIG6F21lEd7HD1cQHYMFka0SeKPqvOS9sh7h/twU6Fmc2ORUQJd7XOKY1y StV98/v1y6PwlhMtfdvRgbN4S18Yy/PdZzporAtK8dAGkOeTcO7+D3w9ZEMtnk96z6lE ie6Od6WSzao9E2Cj5WzspFHrI55IGU/k3UZuSAX/xIBqihjkOA7T+KLYScpgbizaecIM 9IftZD2Ac2cTSgh27Xq+iB7G/pXQtZ35KEmzaHossp2diaes4e/pz8SysK0VjWq72mkZ znTw== X-Gm-Message-State: AOJu0Yy84Gn2ESsXojHb7/dfTwTTRAv78pTJaQKwwspeEa5mNIt6xOU1 K/MkMMMTjglnDSWu75Wnz9VCFh9nWoUvQMb2j5bsZM/8n5XRVxuPp8J6ow== X-Gm-Gg: ASbGncv18n7l9gIrWLeYCW5e5lKXNxcq5lcW+bK/9uydpaR38q1NSbs2/22D8bOsj/j 4xH1UYDSVcScMC4jDIvoUX2v0o+lBH+AGHKMlBEVurn6EkANtc/Lt9oJ8n4eDhcQcrdpvFj99E9 JFIrpAGBengDbUdQ4X23IPEbCHO19cs5WkgJTLnUzRn28dSjwM7NKhI12cxnozqFqtbqYKeNGWa rv12MN8mhHphg1CTi/ZXYFNxuaRwYOMEzyeTLMtL52iS/fL7vKxnvPc4/sqafEzvwqfOCM= X-Google-Smtp-Source: AGHT+IH6+7YUi5w3j95MxDRTkF+rI1JuJVq6qV+XCDlh0o12Ws7soWr+JD0n86FZEhnor2FBVe++Ag== X-Received: by 2002:a92:c243:0:b0:3a7:87f2:b010 with SMTP id e9e14a558f8ab-3ce3a9a5743mr37774435ab.5.1736374949528; Wed, 08 Jan 2025 14:22:29 -0800 (PST) Received: from nuc (192-0-220-237.cpe.teksavvy.com. [192.0.220.237]) by smtp.gmail.com with ESMTPSA id 8926c6da1cb9f-4e68bf67546sm10784462173.42.2025.01.08.14.22.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 08 Jan 2025 14:22:29 -0800 (PST) Date: Wed, 8 Jan 2025 17:22:26 -0500 From: Mark Johnston To: Konstantin Belousov Cc: freebsd-hackers@freebsd.org Subject: Re: widening ticks Message-ID: References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4YT2Ty6LLDz4hjs X-Spamd-Bar: ---- 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] On Thu, Jan 09, 2025 at 12:18:48AM +0200, Konstantin Belousov wrote: > On Wed, Jan 08, 2025 at 04:31:16PM -0500, Mark Johnston wrote: > > The global "ticks" variable counts hardclock ticks, it's widely used in > > the kernel for low-precision timekeeping. The linuxkpi provides a very > > similar variable, "jiffies", but there's an incompatibility: the former > > is a signed int and the latter is an unsigned long. It's not > > particularly easy to paper over this difference, which has been > > responsible for some nasty bugs, and modifying drivers to store the > > jiffies value in a signed int is error-prone and a maintenance burden > > that the linuxkpi is supposed to avoid. > > > > It would be nice to provide a compatible implementation of jiffies. I > > can see a few approaches: > > - Define a 64-bit ticks variable, say ticks64, and make hardclock() > > update both ticks and ticks64. Then #define jiffies ticks64 on 64-bit > > platforms. This is the simplest to implement, but it adds extra work > > to hardclock() and is somewhat ugly. > > - Make ticks an int64_t or a long and convert our native code > > accordingly. This is cleaner but requires a lot of auditing to avoid > > introducing bugs, though perhaps some code could be left unmodified, > > implicitly truncating the value to an int. For example I think > > sched_pctcpu_update() is fine. I've gotten an amd64 kernel to compile > > and boot with this change, but it's hard to be confident in it. This > > approach also has the potential downside of bloating structures that > > store a ticks value, and it can't be MFCed. > > - Introduce a 64-bit ticks variable, ticks64, and > > #define ticks ((int)ticks64). This requires renaming any struct > > fields and local vars named "ticks", of which there's a decent number, > > but that can be done fairly mechanically. > > > > Is there another solution which avoids these pitfalls? If not, should > > we go ahead with one of these approaches? If so, which one? > > You cannot do this in C, but can in asm: > .data > .globl ticksl, ticks > .type ticksl, @object > .type ticks, @object > ticksl: .quad > .size ticksl, 8 > ticks =ticksl /* for little-endian */ > /* ticks =ticksl + 4 for big-endian */ > .size ticks, 4 > > > Then update only ticksl in the hardclock(). Oh, that's better than my proposals. I guess it could be done in the kernel linker script too, but perhaps locore.S is a better place anyway. From nobody Wed Jan 8 23:07:47 2025 X-Original-To: freebsd-hackers@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 4YT3VJ1jB7z5kB0q for ; Wed, 08 Jan 2025 23:07:52 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (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 4YT3VH6CsNz4mkb for ; Wed, 8 Jan 2025 23:07:51 +0000 (UTC) (envelope-from markjdb@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-io1-xd32.google.com with SMTP id ca18e2360f4ac-844e55a981dso9927439f.3 for ; Wed, 08 Jan 2025 15:07:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736377671; x=1736982471; darn=freebsd.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:from:to:cc:subject:date:message-id :reply-to; bh=5CjXydmzIn+pXch1t0g/2W8xP0tvEj8l66Rh/IXCVz4=; b=jcYxQXGFVsAWOUpiZ4vJzyY7BgbhhxIYLHO2c+VMrbRp4gXKivq1o71xuwbUO6tcpM /uNZjXeYUiPpmOqdVk7URM9nn8B9Q89ovPUaJRH8NmD//gjbmQCgaQHDkrQQRQG3hNcb K72I+eIp4AKuCwxuwL1BEVVKk0pZ+BG8263RtRC/itNUIxDIxiFT1I/BFRGD2bObtWQd A8zs3PWk4JKMxqXOiRlpgMDfUtPWb6LBuI2RPbepXYR8pxxSQO8ipJeMr1QFj/JIem4W 4u1w6YRuZEHYpSgPTPVeHhrZ+gwGK7gRIoH3TkiYgajsZEc9kUXPChnQB5lp0aCMpcG6 fRPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736377671; x=1736982471; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=5CjXydmzIn+pXch1t0g/2W8xP0tvEj8l66Rh/IXCVz4=; b=iklWBR2Bs02GF4lMz9vMgtF6xatAiVt6oVx3wNMFvt3vteRjAQy+3/w+xCSL1fMq/R vbeNZrFiqUheRvXNzghGo6tUhsCyfaPQW+4N+a6ufiVSJObeqp4n9iVvkkbXfWcmRHVu G05U9W52mDQ6QdrDT6Jh60IWudqztdqck2GdUjtkc4kmNftDBQ/1y5qBGciVf6ZzWJJl 3/NBZyY7OttEvMmR/p+he/ryletv3HT6RvPmf7nalJSINL+Ix1N1gxfgeWdOKyypETs8 PFsY7NEOtJ0MhMN/VouqJ97M0GacOoIUl3kmcZFOBo+DExUR+jewo1ErhelUdpIxRe9v JfmA== X-Gm-Message-State: AOJu0Yz4B/stLX8hRlJ0YIRFmzkhcBrKnxFbs+me2yJVgDLYiLArihwl 1f7AxJofRB5gII9pVxsZc3FeHsxSIDycpq8Jg5ZY/J+ALTbBklOQWHyY1A== X-Gm-Gg: ASbGncvuWO5dGbUeLvVsN1bF/QEjCbppjDho1GTf6jzOU2ipnG6ZCiWLh2WSZhqO29w wF6twCto8/RQ/+uezIzk7qk6mF4H5lGzSZD/YMeJDRtu9B//kBInymIYzm82XiH07V18Lfnvemk oM1RkXousVklvXTXCsSGOJOQEmcNqWFOj9qtoswIPdXZr9O0LAL4olmLqBtM/Th99Vmr1eslKwT 6hFSremOnDzBwOtXrvTwYo0KCJsXquuGlgvHTCLE2sX6zDkNNdNUQ6rnbW60McDNiZR6Ec= X-Google-Smtp-Source: AGHT+IEHQ0otfPvIkyb6ARSaxzCM3PvFFG0kZTrINwXTWoS8/bhG5/bC4MZHT+lkSneWbxB6xRZEIA== X-Received: by 2002:a05:6e02:1787:b0:3ab:4bea:df97 with SMTP id e9e14a558f8ab-3ce3a9d451emr33392605ab.23.1736377670699; Wed, 08 Jan 2025 15:07:50 -0800 (PST) Received: from nuc (192-0-220-237.cpe.teksavvy.com. [192.0.220.237]) by smtp.gmail.com with ESMTPSA id 8926c6da1cb9f-4ea1b71763asm10703173.103.2025.01.08.15.07.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 08 Jan 2025 15:07:50 -0800 (PST) Date: Wed, 8 Jan 2025 18:07:47 -0500 From: Mark Johnston To: Konstantin Belousov Cc: freebsd-hackers@freebsd.org Subject: Re: widening ticks Message-ID: References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4YT3VH6CsNz4mkb X-Spamd-Bar: ---- 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] On Thu, Jan 09, 2025 at 12:18:48AM +0200, Konstantin Belousov wrote: > On Wed, Jan 08, 2025 at 04:31:16PM -0500, Mark Johnston wrote: > > The global "ticks" variable counts hardclock ticks, it's widely used in > > the kernel for low-precision timekeeping. The linuxkpi provides a very > > similar variable, "jiffies", but there's an incompatibility: the former > > is a signed int and the latter is an unsigned long. It's not > > particularly easy to paper over this difference, which has been > > responsible for some nasty bugs, and modifying drivers to store the > > jiffies value in a signed int is error-prone and a maintenance burden > > that the linuxkpi is supposed to avoid. > > > > It would be nice to provide a compatible implementation of jiffies. I > > can see a few approaches: > > - Define a 64-bit ticks variable, say ticks64, and make hardclock() > > update both ticks and ticks64. Then #define jiffies ticks64 on 64-bit > > platforms. This is the simplest to implement, but it adds extra work > > to hardclock() and is somewhat ugly. > > - Make ticks an int64_t or a long and convert our native code > > accordingly. This is cleaner but requires a lot of auditing to avoid > > introducing bugs, though perhaps some code could be left unmodified, > > implicitly truncating the value to an int. For example I think > > sched_pctcpu_update() is fine. I've gotten an amd64 kernel to compile > > and boot with this change, but it's hard to be confident in it. This > > approach also has the potential downside of bloating structures that > > store a ticks value, and it can't be MFCed. > > - Introduce a 64-bit ticks variable, ticks64, and > > #define ticks ((int)ticks64). This requires renaming any struct > > fields and local vars named "ticks", of which there's a decent number, > > but that can be done fairly mechanically. > > > > Is there another solution which avoids these pitfalls? If not, should > > we go ahead with one of these approaches? If so, which one? > > You cannot do this in C, but can in asm: > .data > .globl ticksl, ticks > .type ticksl, @object > .type ticks, @object > ticksl: .quad > .size ticksl, 8 > ticks =ticksl /* for little-endian */ > /* ticks =ticksl + 4 for big-endian */ > .size ticks, 4 > > > Then update only ticksl in the hardclock(). I implemented your suggestion here: https://reviews.freebsd.org/D48383 From nobody Thu Jan 9 00:03:23 2025 X-Original-To: freebsd-hackers@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 4YT4kc1bmBz5kH1w for ; Thu, 09 Jan 2025 00:03:36 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com [IPv6:2607:f8b0:4864:20::102d]) (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 4YT4kb4bZcz4t0J for ; Thu, 9 Jan 2025 00:03:35 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pj1-x102d.google.com with SMTP id 98e67ed59e1d1-2f44353649aso522828a91.0 for ; Wed, 08 Jan 2025 16:03:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1736381014; x=1736985814; 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=aKEW/bNLBnWvE5gjKBD7Cui/bCTPnEcC3L4SJF6d3VQ=; b=DvrZDe6cwxv0WW3y1Qcd2JMyAvB9Q5m44uLKURF9E4LDNVDu80LY6t2QhDcbD5P0Py 2ZQs3zi1LGYUnE2/2ln3IvEEbc2wghKIBJYN3a59BXD/mVJwlxRMbxxB62S/tFpVlk5G DHow+1jxKhub7aNHYOMD3hp7v4Rs9UqoTJ4jlcU76Tz2A962reG7GzwaQj1ZqapMSEgb 8/9oCwN0s58NZbFXK89W+Px9ttjbjoh5MJ3Tkbagj+NAhrzgRCELELyaPKey8FUqJx67 Z4rR7k20iANYB+Zd6zz3M8CTvj7ZaxZUV6efWzd72qWQvXw+VXLUpnbGHngoiRx+RFsD Dmuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736381014; x=1736985814; 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=aKEW/bNLBnWvE5gjKBD7Cui/bCTPnEcC3L4SJF6d3VQ=; b=lH/kVrUOY7kZYYJkae9ycLIkuFwzYuks+e2j+Sc5r+6/u8fWYQcAwVigkQpZpMHYqa QG1Sm54+/IATwDsj6ZJ/zca7fOgqigLNYU5IL8EiwvTzlaV6PAxlP5MsQF/ZSH49JtRj 2sjbsfWr2D+l1u4UMS52Q+6SwUni/c2QcILN2Pamuagqt8ZBP/FZIGhnSAWcAfb9SoEj X0Gl906xZqPG/YoXYJ6cAxOovwjjkyWtlf+0Wra33tlttrAbuenFDMWGsSDn3K/noWub x3TIcOhOfNM0/vM1f+IYXNLYdk10TPsWdbuMm/b7ztNAzZSBrIp5+M+K2S/RIOiYIBnb UfFg== X-Gm-Message-State: AOJu0YzE0Eg0hSoL861ZB7D1rIF3RlTSxoCOLCISLmsrOt5/MX+eW25u FhZRAWNjJLdsoqBQrp+FyX5LwlcSSuv66bvGY3H0c7L1+/u8tNkPjc3W1fH49K5QDV/EGVodWBq aHc2UG26V69CRWUs7s3juioEKlWgfnuRb7LofaQ== X-Gm-Gg: ASbGncvVobIphWRXSrRlKUINfNUxXzmEaTiZyDhmtSWp7PVSb5/G03UKY7YsfTkf9sY qnZ62GT8yq8uaHK1Qr3QzkMdtiWT1SEezW6U8ZA== X-Google-Smtp-Source: AGHT+IFrETcfwwyjcUie39xbBWgXgfkqLFmdbf+SXYCX6FGEAFdlb4/tT81I+YgMo4y/QuZyyFSdNpwfCMeObVYAGrA= X-Received: by 2002:a17:90b:37ce:b0:2ee:dd9b:e3e8 with SMTP id 98e67ed59e1d1-2f548ea5390mr7659094a91.8.1736381014348; Wed, 08 Jan 2025 16:03:34 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Wed, 8 Jan 2025 17:03:23 -0700 X-Gm-Features: AbW1kvYKhxCFE7hRD9KEz4Fhc4oJTMLOuObGuckUlKOCrDE4FvPlr3KJ6r59tyg Message-ID: Subject: Re: widening ticks To: Mark Johnston Cc: freebsd-hackers@freebsd.org Content-Type: multipart/alternative; boundary="0000000000008e3376062b3ab53b" X-Rspamd-Queue-Id: 4YT4kb4bZcz4t0J X-Spamd-Bar: ---- 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] --0000000000008e3376062b3ab53b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jan 8, 2025 at 3:20=E2=80=AFPM Mark Johnston wr= ote: > On Wed, Jan 08, 2025 at 02:51:31PM -0700, Warner Losh wrote: > > On Wed, Jan 8, 2025 at 2:31=E2=80=AFPM Mark Johnston wrote: > > > > > The global "ticks" variable counts hardclock ticks, it's widely used = in > > > the kernel for low-precision timekeeping. The linuxkpi provides a ve= ry > > > similar variable, "jiffies", but there's an incompatibility: the form= er > > > is a signed int and the latter is an unsigned long. It's not > > > particularly easy to paper over this difference, which has been > > > responsible for some nasty bugs, and modifying drivers to store the > > > jiffies value in a signed int is error-prone and a maintenance burden > > > that the linuxkpi is supposed to avoid. > > > > > > It would be nice to provide a compatible implementation of jiffies. = I > > > can see a few approaches: > > > - Define a 64-bit ticks variable, say ticks64, and make hardclock() > > > update both ticks and ticks64. Then #define jiffies ticks64 on > 64-bit > > > platforms. This is the simplest to implement, but it adds extra wo= rk > > > to hardclock() and is somewhat ugly. > > > - Make ticks an int64_t or a long and convert our native code > > > accordingly. This is cleaner but requires a lot of auditing to avo= id > > > introducing bugs, though perhaps some code could be left unmodified= , > > > implicitly truncating the value to an int. For example I think > > > sched_pctcpu_update() is fine. I've gotten an amd64 kernel to > compile > > > and boot with this change, but it's hard to be confident in it. Th= is > > > approach also has the potential downside of bloating structures tha= t > > > store a ticks value, and it can't be MFCed. > > > - Introduce a 64-bit ticks variable, ticks64, and > > > #define ticks ((int)ticks64). This requires renaming any struct > > > fields and local vars named "ticks", of which there's a decent > number, > > > but that can be done fairly mechanically. > > > > > > Is there another solution which avoids these pitfalls? If not, shoul= d > > > we go ahead with one of these approaches? If so, which one? > > > > > > > So solution (1) is MFC-able, I think, so I like it. > > (2) Isn't, but is likely a better long-term solution. > > (3) is a non-starter since ticks is too common a name to #define. > > Why is that a non-starter? This is just in the kernel, and as you note > below, shadowing ticks isn't a great idea anyway. (I don't really want > to go down this path in any case, but I'm wondering if I misunderstood > something.) > I worry about it leaking to userland. And I worry about the third party drivers that can't tolerate it as a #define. That's all... > > I could easily see a situation where we do (1) and then convert all > current > > users of ticks to be ticks64. This could proceed one at a time with as > much > > haste or caution as we need. Once we convert all of them over, we could > > delete ticks and then there'd be no extra work in hardclock. This too > would > > be MFC-able. > > > > sys/net/iflib.c: uint64_t this_tick =3D ticks; > > sys/netinet/tcp_subr.c: < (u_int)ticks))) { > > > > look fun! We also shadow it in a lot of places. The TCP stack uses it a > lot > > with a bunch of different variables, struct entries, etc, including RAC= K > > and BBR. > > The 802.11 stack uses it a bunch. As to a bunch of drivers, sometimes > > shadowing > > other times not. > > > > It would be a lot to audit all this, so I think having the new API in > place > > might be > > better, and incrementally converting / removing the shadowing (even if = it > > isn't > > completely in scoe, using ticks as a local variable is begging for > trouble). > > Yeah, looking some more, I think having a flag day will make this too > painful. > > So then I guess the question is, do we provide an int64_t ticks64 or a > long ticksl? Do we have any 32-bit platforms where a 64-bit cmpset in > hardclock() would be a problem? > I don't think so. I kinda like kib's notion too... > > Warner > > > > Also I see both jiffies and jiffies_64 defined. Does that matter at all= ? > > They differ only on 32-bit systems I believe. On such systems there is > a 64-bit tick counter, jiffies_64, but it might not be atomic. > Ah! Warner --0000000000008e3376062b3ab53b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Jan 8, = 2025 at 3:20=E2=80=AFPM Mark Johnston <markj@freebsd.org> wrote:
On Wed, Jan 08, 2025 at 02:51:31PM -0700, Warner Losh = wrote:
> On Wed, Jan 8, 2025 at 2:31=E2=80=AFPM Mark Johnston <markj@freebsd.org> wrote:<= br> >
> > The global "ticks" variable counts hardclock ticks, it&= #39;s widely used in
> > the kernel for low-precision timekeeping.=C2=A0 The linuxkpi prov= ides a very
> > similar variable, "jiffies", but there's an incompa= tibility: the former
> > is a signed int and the latter is an unsigned long.=C2=A0 It'= s not
> > particularly easy to paper over this difference, which has been > > responsible for some nasty bugs, and modifying drivers to store t= he
> > jiffies value in a signed int is error-prone and a maintenance bu= rden
> > that the linuxkpi is supposed to avoid.
> >
> > It would be nice to provide a compatible implementation of jiffie= s.=C2=A0 I
> > can see a few approaches:
> > - Define a 64-bit ticks variable, say ticks64, and make hardclock= ()
> >=C2=A0 =C2=A0update both ticks and ticks64.=C2=A0 Then #define jif= fies ticks64 on 64-bit
> >=C2=A0 =C2=A0platforms.=C2=A0 This is the simplest to implement, b= ut it adds extra work
> >=C2=A0 =C2=A0to hardclock() and is somewhat ugly.
> > - Make ticks an int64_t or a long and convert our native code
> >=C2=A0 =C2=A0accordingly.=C2=A0 This is cleaner but requires a lot= of auditing to avoid
> >=C2=A0 =C2=A0introducing bugs, though perhaps some code could be l= eft unmodified,
> >=C2=A0 =C2=A0implicitly truncating the value to an int.=C2=A0 For = example I think
> >=C2=A0 =C2=A0sched_pctcpu_update() is fine.=C2=A0 I've gotten = an amd64 kernel to compile
> >=C2=A0 =C2=A0and boot with this change, but it's hard to be co= nfident in it.=C2=A0 This
> >=C2=A0 =C2=A0approach also has the potential downside of bloating = structures that
> >=C2=A0 =C2=A0store a ticks value, and it can't be MFCed.
> > - Introduce a 64-bit ticks variable, ticks64, and
> >=C2=A0 =C2=A0#define ticks ((int)ticks64).=C2=A0 This requires ren= aming any struct
> >=C2=A0 =C2=A0fields and local vars named "ticks", of whi= ch there's a decent number,
> >=C2=A0 =C2=A0but that can be done fairly mechanically.
> >
> > Is there another solution which avoids these pitfalls?=C2=A0 If n= ot, should
> > we go ahead with one of these approaches?=C2=A0 If so, which one?=
> >
>
> So solution (1) is MFC-able, I think, so I like it.
> (2) Isn't, but is likely a better long-term solution.
> (3) is a non-starter since ticks is too common a name to #define.

Why is that a non-starter?=C2=A0 This is just in the kernel, and as you not= e
below, shadowing ticks isn't a great idea anyway.=C2=A0 (I don't re= ally want
to go down this path in any case, but I'm wondering if I misunderstood<= br> something.)

I worry about it leaking to= userland. And I worry about the third party drivers
that can'= ;t tolerate it as a #define. That's all...
=C2=A0
> I could easily see a situation where we do (1) and then convert all cu= rrent
> users of ticks to be ticks64. This could proceed one at a time with as= much
> haste or caution as we need. Once we convert all of them over, we coul= d
> delete ticks and then there'd be no extra work in hardclock. This = too would
> be MFC-able.
>
> sys/net/iflib.c: uint64_t this_tick =3D ticks;
> sys/netinet/tcp_subr.c:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0< (u_int)t= icks))) {
>
> look fun! We also shadow it in a lot of places. The TCP stack uses it = a lot
> with a bunch of different variables, struct entries, etc, including RA= CK
> and BBR.
> The 802.11 stack uses it a bunch.=C2=A0 As to a bunch of drivers, some= times
> shadowing
> other times not.
>
> It would be a lot to audit all this, so I think having the new API in = place
> might be
> better, and incrementally converting / removing the shadowing (even if= it
> isn't
> completely in scoe, using ticks as a local variable is begging for tro= uble).

Yeah, looking some more, I think having a flag day will make this too
painful.

So then I guess the question is, do we provide an int64_t ticks64 or a
long ticksl?=C2=A0 Do we have any 32-bit platforms where a 64-bit cmpset in=
hardclock() would be a problem?

I don&#= 39;t think so. I kinda like kib's notion too...
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex"> > Warner
>
> Also I see both jiffies and jiffies_64 defined. Does that matter at al= l?

They differ only on 32-bit systems I believe.=C2=A0 On such systems there i= s
a 64-bit tick counter, jiffies_64, but it might not be atomic.

Ah!

Warner=C2=A0
--0000000000008e3376062b3ab53b-- From nobody Thu Jan 9 19:08:47 2025 X-Original-To: freebsd-hackers@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 4YTZ8F2NNGz5jqx9 for ; Thu, 09 Jan 2025 19:09:01 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (mailhost.m5p.com [74.104.188.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 (2048 bits) client-digest SHA256) (Client CN "m5p.com", Issuer "R10" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4YTZ8D2H6mz4j39 for ; Thu, 9 Jan 2025 19:09:00 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of george+freebsd@m5p.com designates 74.104.188.4 as permitted sender) smtp.mailfrom=george+freebsd@m5p.com; dmarc=none Received: from [IPV6:2001:470:1f07:15ff::26] (court.m5p.com [IPv6:2001:470:1f07:15ff:0:0:0:26]) (authenticated bits=0) by mailhost.m5p.com (8.18.1/8.17.1) with ESMTPSA id 509J8lLN040768 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Thu, 9 Jan 2025 14:08:53 -0500 (EST) (envelope-from george+freebsd@m5p.com) Message-ID: Date: Thu, 9 Jan 2025 14:08:47 -0500 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: FreeBSD Hackers From: George Mitchell Subject: lang/cython broken on FreeBSD 14? Autocrypt: addr=george+freebsd@m5p.com; keydata= xjMEZaHDbxYJKwYBBAHaRw8BAQdA2W6oBfS8haXY0/Ft4zS1OTLYfC8EBIADPTgMQdh85C3N KEdlb3JnZSBNaXRjaGVsbCA8Z2VvcmdlK2ZyZWVic2RAbTVwLmNvbT7CmQQTFgoAQRYhBDpv v9n4+UzMLAJ8EZocD3futmd9BQJlocSiAhsDBQkFo5qABQsJCAcCAiICBhUKCQgLAgQWAgMB Ah4HAheAAAoJEJocD3futmd9SxwBAJUi6DNdVhWCZBTv5XGy1g0JgApLWe/3S0M0zz9sn7/L AQCcJcV5k5s2rt9J5C1AUm6XVsuneVvIWXO5j1GKWk0NC844BGWhw28SCisGAQQBl1UBBQEB B0AaFz/6B95RRvjOdLZr5fSdhuIHvwr24H3ePDZSw6wlUwMBCAfCfgQYFgoAJhYhBDpvv9n4 +UzMLAJ8EZocD3futmd9BQJlocNvAhsMBQkFo5qAAAoJEJocD3futmd9RXsBANwRD9RE56F6 /jeZOrujHICLcgPiOt50Y6866v9OUTjUAP9GlC1aopfBpNwuPLJBam7oBaGqvY98VDhzOjoT 7DNbCQ== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------nR3AHqCtLWbuz079ybWkFXmW" X-Spam-Status: No, score=0.0 required=10.0 tests=HELO_NO_DOMAIN autolearn=unavailable autolearn_force=no version=4.0.1 X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on mattapan.m5p.com X-Rspamd-Queue-Id: 4YTZ8D2H6mz4j39 X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.18 / 15.00]; SIGNED_PGP(-2.00)[]; MIME_BASE64_TEXT_BOGUS(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.89)[-0.888]; R_SPF_ALLOW(-0.20)[+a]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; MIME_BASE64_TEXT(0.10)[]; XM_UA_NO_VERSION(0.01)[]; TAGGED_FROM(0.00)[freebsd]; TO_DN_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; DMARC_NA(0.00)[m5p.com]; RCPT_COUNT_ONE(0.00)[1]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_ALL(0.00)[]; ASN(0.00)[asn:701, ipnet:74.104.0.0/16, country:US]; RCVD_COUNT_ONE(0.00)[1]; MLMMJ_DEST(0.00)[freebsd-hackers@FreeBSD.org]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; HAS_ATTACHMENT(0.00)[]; R_DKIM_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~] This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------nR3AHqCtLWbuz079ybWkFXmW Content-Type: multipart/mixed; boundary="------------pa98iGWeXitUZmLD9UzCsfuD"; protected-headers="v1" From: George Mitchell To: FreeBSD Hackers Message-ID: Subject: lang/cython broken on FreeBSD 14? --------------pa98iGWeXitUZmLD9UzCsfuD Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 QWZ0ZXIgYSBmYWlybHkgc3VjY2Vzc2Z1bCBGcmVlQlNEIDEzLT4xNCBiYXNlIHN5c3RlbSB1 cGRhdGUgbGFzdCB3ZWVrLA0KSSd2ZSBzcGVudCBtYW55IGRheXMgdXBkYXRpbmcgbXkgcG9y dHMgdHJlZS4gUXVpdGUgYSBmZXcgcG9ydHMgdGhhdA0KaW52b2x2ZSBDeXRob24sIGluY2x1 ZGluZyBzb21lIHdoZXJlIHRoZSBpbnZvbHZlbWVudCBpcyBvYnZpb3VzIHN1Y2gNCmFzIGRh dGFiYXNlcy9weS1zcWxpdGUzIGFuZCBvdGhlcnMgd2hlcmUgdGhlIGludm9sdmVtZW50IGlz IHN1cnByaXNpbmcNCmFuZCBpbmRpcmVjdCwgc3VjaCBhcyBwcmludC90ZXgtZHZpcHNrLCBm YWlsZWQuICBJIGhhZCBubyBpZGVhIHRoYXQNCnRoZXJlIGlzIGEgbmV3ZXIgdmVyc2lvbiBv ZiBDeXRob24gdW50aWwgSSBkZWx2ZWQgaW50byBidWd6aWxsYS4gIExvDQphbmQgYmVob2xk LCB1cGRhdGluZyBzZWVtcyB0byBoYXZlIGZpeGVkIGFsbCBteSBwcm9ibGVtcyENCg0KVGhl cmUncyBub3QgYSBwZWVwIGFib3V0IHRoaXMgaW4gL3Vzci9wb3J0cy9VUERBVElORy4gIE1v cmUgdG8gdGhlDQpwb2ludCwgd291bGQgaXQgYmUgYXBwcm9wcmlhdGUgdG8gYWRkOg0KDQpC Uk9LRU5fRnJlZUJTRF8xND0gICBEb2VzIG5vdCB3b3JrIG9uIEZyZWVCU0QgMTQ7IHVzZSBs YW5nL2N5dGhvbjMgaW5zdGVhZC4NCg0KdG8gbGFuZy9jeXRob24vTWFrZWZpbGU/DQoNCihJ IGFkZGVkIGEgY29tbWVudCBhYm91dCB0aGlzIHRvIGJ1ZyAyODExNDUuKSAgICAgICAgICAg ICAtLSBHZW9yZ2UNCg== --------------pa98iGWeXitUZmLD9UzCsfuD-- --------------nR3AHqCtLWbuz079ybWkFXmW Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wnsEABYIACMWIQQ6b7/Z+PlMzCwCfBGaHA937rZnfQUCZ4AevwUDAAAAAAAKCRCaHA937rZnfZhh AQCakat0tbjxDBDQLTgVbiWKcYsZtxcAhBm6iM0aY3b8TwEAio1b9Tyc4wNL/vglPAjXkJMQSQ6y BXuX9oNtAdqeRQ8= =bZT2 -----END PGP SIGNATURE----- --------------nR3AHqCtLWbuz079ybWkFXmW-- From nobody Thu Jan 9 20:53:43 2025 X-Original-To: freebsd-hackers@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 4YTcTD5KyTz5k2Dy for ; Thu, 09 Jan 2025 20:53:52 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (mailhost.m5p.com [74.104.188.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 (2048 bits) client-digest SHA256) (Client CN "m5p.com", Issuer "R10" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4YTcTC4Gppz4tD1 for ; Thu, 9 Jan 2025 20:53:51 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of george+freebsd@m5p.com designates 74.104.188.4 as permitted sender) smtp.mailfrom=george+freebsd@m5p.com; dmarc=none Received: from [IPV6:2001:470:1f07:15ff::26] (court.m5p.com [IPv6:2001:470:1f07:15ff:0:0:0:26]) (authenticated bits=0) by mailhost.m5p.com (8.18.1/8.17.1) with ESMTPSA id 509KrhSV041038 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Thu, 9 Jan 2025 15:53:49 -0500 (EST) (envelope-from george+freebsd@m5p.com) Message-ID: <05c850e8-0a57-4fa2-baf8-af59259df131@m5p.com> Date: Thu, 9 Jan 2025 15:53:43 -0500 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: lang/cython broken on FreeBSD 14? From: George Mitchell To: FreeBSD Hackers References: Content-Language: en-US Autocrypt: addr=george+freebsd@m5p.com; keydata= xjMEZaHDbxYJKwYBBAHaRw8BAQdA2W6oBfS8haXY0/Ft4zS1OTLYfC8EBIADPTgMQdh85C3N KEdlb3JnZSBNaXRjaGVsbCA8Z2VvcmdlK2ZyZWVic2RAbTVwLmNvbT7CmQQTFgoAQRYhBDpv v9n4+UzMLAJ8EZocD3futmd9BQJlocSiAhsDBQkFo5qABQsJCAcCAiICBhUKCQgLAgQWAgMB Ah4HAheAAAoJEJocD3futmd9SxwBAJUi6DNdVhWCZBTv5XGy1g0JgApLWe/3S0M0zz9sn7/L AQCcJcV5k5s2rt9J5C1AUm6XVsuneVvIWXO5j1GKWk0NC844BGWhw28SCisGAQQBl1UBBQEB B0AaFz/6B95RRvjOdLZr5fSdhuIHvwr24H3ePDZSw6wlUwMBCAfCfgQYFgoAJhYhBDpvv9n4 +UzMLAJ8EZocD3futmd9BQJlocNvAhsMBQkFo5qAAAoJEJocD3futmd9RXsBANwRD9RE56F6 /jeZOrujHICLcgPiOt50Y6866v9OUTjUAP9GlC1aopfBpNwuPLJBam7oBaGqvY98VDhzOjoT 7DNbCQ== In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------Aer0VOlE0XjRLyBB907Trnso" X-Spam-Status: No, score=0.0 required=10.0 tests=HELO_NO_DOMAIN autolearn=unavailable autolearn_force=no version=4.0.1 X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on mattapan.m5p.com X-Rspamd-Queue-Id: 4YTcTC4Gppz4tD1 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.25 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; NEURAL_HAM_SHORT(-0.96)[-0.957]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; R_SPF_ALLOW(-0.20)[+a:c]; MIME_BASE64_TEXT(0.10)[]; XM_UA_NO_VERSION(0.01)[]; FROM_HAS_DN(0.00)[]; RCVD_TLS_ALL(0.00)[]; TAGGED_FROM(0.00)[freebsd]; TO_DN_ALL(0.00)[]; DMARC_NA(0.00)[m5p.com]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; HAS_ATTACHMENT(0.00)[]; ASN(0.00)[asn:701, ipnet:74.104.0.0/16, country:US]; RCPT_COUNT_ONE(0.00)[1]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; MLMMJ_DEST(0.00)[freebsd-hackers@FreeBSD.org]; MID_RHS_MATCH_FROM(0.00)[]; R_DKIM_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~] This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------Aer0VOlE0XjRLyBB907Trnso Content-Type: multipart/mixed; boundary="------------JZx0M91UYpJTmhAOw6C8XToq"; protected-headers="v1" From: George Mitchell To: FreeBSD Hackers Message-ID: <05c850e8-0a57-4fa2-baf8-af59259df131@m5p.com> Subject: Re: lang/cython broken on FreeBSD 14? References: In-Reply-To: --------------JZx0M91UYpJTmhAOw6C8XToq Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMS85LzI1IDE0OjA4LCBHZW9yZ2UgTWl0Y2hlbGwgd3JvdGU6DQo+IEFmdGVyIGEgZmFp cmx5IHN1Y2Nlc3NmdWwgRnJlZUJTRCAxMy0+MTQgYmFzZSBzeXN0ZW0gdXBkYXRlIGxhc3Qg d2VlaywNCj4gSSd2ZSBzcGVudCBtYW55IGRheXMgdXBkYXRpbmcgbXkgcG9ydHMgdHJlZS4g UXVpdGUgYSBmZXcgcG9ydHMgdGhhdA0KPiBpbnZvbHZlIEN5dGhvbiwgaW5jbHVkaW5nIHNv bWUgd2hlcmUgdGhlIGludm9sdmVtZW50IGlzIG9idmlvdXMgc3VjaA0KPiBhcyBkYXRhYmFz ZXMvcHktc3FsaXRlMyBhbmQgb3RoZXJzIHdoZXJlIHRoZSBpbnZvbHZlbWVudCBpcyBzdXJw cmlzaW5nDQo+IGFuZCBpbmRpcmVjdCwgc3VjaCBhcyBwcmludC90ZXgtZHZpcHNrLCBmYWls ZWQuwqAgSSBoYWQgbm8gaWRlYSB0aGF0DQo+IHRoZXJlIGlzIGEgbmV3ZXIgdmVyc2lvbiBv ZiBDeXRob24gdW50aWwgSSBkZWx2ZWQgaW50byBidWd6aWxsYS7CoCBMbw0KPiBhbmQgYmVo b2xkLCB1cGRhdGluZyBzZWVtcyB0byBoYXZlIGZpeGVkIGFsbCBteSBwcm9ibGVtcyENCj4g DQo+IFRoZXJlJ3Mgbm90IGEgcGVlcCBhYm91dCB0aGlzIGluIC91c3IvcG9ydHMvVVBEQVRJ TkcuwqAgTW9yZSB0byB0aGUNCj4gcG9pbnQsIHdvdWxkIGl0IGJlIGFwcHJvcHJpYXRlIHRv IGFkZDoNCj4gDQo+IEJST0tFTl9GcmVlQlNEXzE0PcKgwqAgRG9lcyBub3Qgd29yayBvbiBG cmVlQlNEIDE0OyB1c2UgbGFuZy9jeXRob24zIGluc3RlYWQuDQo+IA0KPiB0byBsYW5nL2N5 dGhvbi9NYWtlZmlsZT8NCj4gDQo+IChJIGFkZGVkIGEgY29tbWVudCBhYm91dCB0aGlzIHRv IGJ1ZyAyODExNDUuKcKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAtLSBHZW9yZ2UNCg0KQXMg bm90ZWQgaW4gYnVnIDI4MTE0NSwgSSBhbSBvdmVyc2ltcGxpZnlpbmcgdG8gc2F5IHRoYXQg Y3l0aG9uIGlzDQpicm9rZW4gb24gRkJTRDE0OyBzb21lIG90aGVyIHBvcnRzIHJlcXVpcmUg Y3l0aG9uIGluc3RlYWQgaW4gb2YgY3l0aG9uMy4NCkJ1dCBzd2l0Y2hpbmcgdG8gY3l0aG9u MyBzb2x2ZXMgTUFOWSBvZiB0aGUgcHJvYmxlbXMuICBTbyBpdCBpcyB0b28gc29vbg0KdG8g bWFyayBpdCBCUk9LRU4gb24gRkJTRDE0LiAgU29ycnkhICAgICAgICAgICAgICAgICAgICAg ICAgICAtLSBHZW9yZ2UNCg== --------------JZx0M91UYpJTmhAOw6C8XToq-- --------------Aer0VOlE0XjRLyBB907Trnso Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wnsEABYIACMWIQQ6b7/Z+PlMzCwCfBGaHA937rZnfQUCZ4A3VwUDAAAAAAAKCRCaHA937rZnfRTU AQCtjHI0BtY1DZXedVOrdDcB/zEU+0Rc3lx9bJduM5USSQEArZZqUXxRVV49GaKcVBgc+3VBSYqb e0EksyCOqIwnngQ= =TEoL -----END PGP SIGNATURE----- --------------Aer0VOlE0XjRLyBB907Trnso-- From nobody Fri Jan 10 00:30:54 2025 X-Original-To: freebsd-hackers@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 4YTjJN58gCz5kLyK for ; Fri, 10 Jan 2025 00:31:32 +0000 (UTC) (envelope-from dan.f.shelton@gmail.com) Received: from mail-oo1-xc35.google.com (mail-oo1-xc35.google.com [IPv6:2607:f8b0:4864:20::c35]) (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 4YTjJN0STtz4CYw for ; Fri, 10 Jan 2025 00:31:32 +0000 (UTC) (envelope-from dan.f.shelton@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=OjQGNPBo; spf=pass (mx1.freebsd.org: domain of dan.f.shelton@gmail.com designates 2607:f8b0:4864:20::c35 as permitted sender) smtp.mailfrom=dan.f.shelton@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-oo1-xc35.google.com with SMTP id 006d021491bc7-5f6ffbfb338so287247eaf.3 for ; Thu, 09 Jan 2025 16:31:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736469090; x=1737073890; darn=freebsd.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=IYQb7ChUQDj0geTSs1sfaQ0kKSSbJ/kdNKf3j2L/Dys=; b=OjQGNPBo2xgEpYD8ZW8hkx7HeonTPRKbAa+2/SihuPMr/0Cs6fEeXS/Vthgsr6MC8F 2LmVz9fvuppuWmo9xq6MT74584WW7kwpuBXPJxN4g0sBMKcQdap8jn3IbPwCfPysAHfO S/7GA3ddg1tjb8geGlxE25e4ckohCEsw8KLDT0ZM/tDKQSHZDQ6za6CTvKzCDArAIUYo wV0+On8QdeiIQ8QsB5EGI5imS7BT7RNpnRx1jiKrSX8VCTycbluq7GXab43+brZCHHYS rSZr0bUsp9LNipTqT4Yb3oJdzithSuZjTQtCYLHWZt2kU5AULJHXZq3pTUFVqetbZThX SykA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736469090; x=1737073890; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=IYQb7ChUQDj0geTSs1sfaQ0kKSSbJ/kdNKf3j2L/Dys=; b=Eu00M4m03k7vB6YwB7KwJhnSYCIybqMN2C3idZeojaMJilsfYuH7Wm/Gf82ws2RzCq HzKt+vPyT+IgyhcoAwnJJxoulcGcWM1b4xT57Jlu18JfRjklXdHjvTMze15DG/rfdZeN Z0RJMViDrY4WgjM3Jl230d1BNh1jU/FL8XSVRW1p1eQhBXoyipbq32omCJszGAPolzQ8 6Bir2q7cyEle5TBE4VckopMY0Jl7xIUaAofrkwGvE6UwciBJKfnGY5zlX7C1gc+1gSPo zjeClLWEyHkf4KkjaaJ28DzmBUhnWThQOMztp/OgQgXFBzBk4M2qhUMnFRU/t3qf4eps zN0Q== X-Gm-Message-State: AOJu0YzF6jCBPAsNJvkT3lptgSbCk+jaV9f4atff+orLfSs4eFF6LW+G OArDmby/7odnXJ+ZeLjuWpEykD2N15pepmeERo6jwXslR0lN6xlgeEyzCKKJqO+tPvNDUebqhVe 8Le7o6avD/m5UbYbSIztBRgVxFx6nybaC X-Gm-Gg: ASbGnctCaNqnDXqxeGxEB0F+bwEwP9pM1Zpgn8lCrT6L/ChZMryJ2yTpNFccpGqtUj+ 83Xq7X6ea1479rNU0u7hM/RgQmLyHk0NmgPMU9X0= X-Google-Smtp-Source: AGHT+IEsE5pN0Ype5djzwR3y9nuf3Xr4V1f8zMndWyu772Kjt6l4rERSKmiNvICk7ydffOxs+zp+on4IefSTGiKJOx0= X-Received: by 2002:a05:6871:d087:b0:29e:57ec:34c3 with SMTP id 586e51a60fabf-2aa069a8d6fmr4104027fac.32.1736469090622; Thu, 09 Jan 2025 16:31:30 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 From: Dan Shelton Date: Fri, 10 Jan 2025 01:30:54 +0100 X-Gm-Features: AbW1kvZZxy3cGiXAT3T-qi8jW3dYj73Xjm7R8baZfqBIwscnJ0Co5y5xsU0RZVw Message-ID: Subject: WRITE_SAME support in FreeBSD nfsd NFSv4.1 mode? To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4YTjJN0STtz4CYw X-Spamd-Bar: - X-Spamd-Result: default: False [-1.62 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_SPAM_SHORT(0.38)[0.376]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[text/plain]; TAGGED_FROM(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FREEMAIL_FROM(0.00)[gmail.com]; FROM_HAS_DN(0.00)[]; MISSING_XM_UA(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MID_RHS_MATCH_FROMTLD(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::c35:from] Hello! Does FreeBSD nfsd support the WRITE_SAME request in NFSv4.1 mode? Dan -- Dan Shelton - Cluster Specialist Win/Lin/Bsd From nobody Fri Jan 10 01:59:41 2025 X-Original-To: freebsd-hackers@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 4YTlGS6SPrz5kThR for ; Fri, 10 Jan 2025 02:00:00 +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 4YTlGR6MLJz4Kjg for ; Fri, 10 Jan 2025 01:59:59 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=jmHAgH9C; 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; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-ed1-x52a.google.com with SMTP id 4fb4d7f45d1cf-5d9882a936eso2752612a12.3 for ; Thu, 09 Jan 2025 17:59:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736474398; x=1737079198; 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=0cWgRbVUczNMKa6f4v7/g29AghjiPkc7UGqyu6AX3vY=; b=jmHAgH9C/Kdlks9JUOuzbF8MDvNnCsktONd1tgKWVT6+8CTQYkz5kzKb/22pJmavHL uBlmoMw7d6Ohv6kJtzsJoRGgHIVTULtU30y9IQgDLFM/jRRQEHPYhfFVtjmUftYFa5hU VQIAfx/VyrG18r8foEPKBfyXFuuzaKp6pdxgEJV6f4fnleln1mZjMfGLqbTNbo1OQQ48 xowooIILtF1Fe7eCCCnMRkf5UinYiYV2wjXsciP9hF4AoZwOEZkZTUPD43YaI+PPeLIX 0+g1b/Yyra8zbCfDHBCY/AOmflw5Gf1ehjqAA6d1Hll+xBLdINzasp1zQX1TPkigpwna TQ1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736474398; x=1737079198; 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=0cWgRbVUczNMKa6f4v7/g29AghjiPkc7UGqyu6AX3vY=; b=sM9wL87Bq3UBsyMe0GO6lP47QXCzKQTJJ8T4o8GHC98ed1c9qTngfob0/+gCw+Mmwz YIupGYUmIyEkldDEuIwMOwgddH613BcOpauhr1KvHU+Aq2HJ/F7N4fTNlDHLJit/x8fJ R2/v3gqvznozp55eOu9zXAc9CmVmkedhVNp1aDgD1jI5aFOBU2G5bpIx4yfoFB1L0HBo B4woT+4bmzC4fwrmI2LI61+IA6SUydfMJXFxEZtjXK3IL0IQ8EEH37GddS8k7uftO08z VjIgTNEhRGAMkDJfKhlx95cTQqZ/nJxCQRPrf93SqnBLTuzef3TWZRmvcSDTleP1tZOx gZug== X-Gm-Message-State: AOJu0YyFX4FOfx7xTrP2vmG/WWUsyrQYgq0C+HkJAFmdOnwVKFg/u51O xzeDEmTob0rBPSrx6DXRAb9K4kbYq48xwdaNKsWqrtlSFebxwCuQ+kphlzz7P+o1P8UTCtXSTPK qhRb+cM0DK74MGf/Ycq7UYfsnpdo5 X-Gm-Gg: ASbGnctu7qcjyNP1qEHptnkXVlfajh6Ai2/OgUTFxEYO7O7vRBf/xOIlZ2cMWkWxJBa ns+ndkCG/rQmbDuhKenbVG2aPAlbz/8YmiEwJNfc+pDD92nVGqkXmlGz4Sl2nUc8INFQAl/8= X-Google-Smtp-Source: AGHT+IHNY40Xiniv51LFMhNolp4yAjS13XEWXEaFciCnc8+6W0RDEolrzlss83tE8OdgK5SbqIgJ6CJiRSHLh617a98= X-Received: by 2002:a05:6402:4402:b0:5d3:ba42:e9d5 with SMTP id 4fb4d7f45d1cf-5d972e06b36mr7640419a12.9.1736474398269; Thu, 09 Jan 2025 17:59:58 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 References: In-Reply-To: From: Rick Macklem Date: Thu, 9 Jan 2025 17:59:41 -0800 X-Gm-Features: AbW1kvYYGigwJH5r49DYhZbtAwr2JGp84dZTsLjnPiZYbCsMUH4fmwQGCuue8Yk Message-ID: Subject: Re: WRITE_SAME support in FreeBSD nfsd NFSv4.1 mode? To: Dan Shelton Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4YTlGR6MLJz4Kjg X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.99 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.992]; 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)[]; RCPT_COUNT_TWO(0.00)[2]; FREEMAIL_FROM(0.00)[gmail.com]; FREEMAIL_TO(0.00)[gmail.com]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; TAGGED_FROM(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; MISSING_XM_UA(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; MLMMJ_DEST(0.00)[freebsd-hackers@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]; TAGGED_RCPT(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::52a:from] On Thu, Jan 9, 2025 at 4:31=E2=80=AFPM Dan Shelton wrote: > > Hello! > > Does FreeBSD nfsd support the WRITE_SAME request in NFSv4.1 mode? Not at this time, I'm afraid. Maybe in a future release, rick > > Dan > -- > Dan Shelton - Cluster Specialist Win/Lin/Bsd > From nobody Fri Jan 10 04:13:50 2025 X-Original-To: freebsd-hackers@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 4YTpFd5Mqpz5kgnb for ; Fri, 10 Jan 2025 04:14:29 +0000 (UTC) (envelope-from dan.f.shelton@gmail.com) Received: from mail-oa1-x35.google.com (mail-oa1-x35.google.com [IPv6:2001:4860:4864:20::35]) (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 4YTpFc6ryHz4XlH for ; Fri, 10 Jan 2025 04:14:28 +0000 (UTC) (envelope-from dan.f.shelton@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b="OUBMzuf/"; spf=pass (mx1.freebsd.org: domain of dan.f.shelton@gmail.com designates 2001:4860:4864:20::35 as permitted sender) smtp.mailfrom=dan.f.shelton@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-oa1-x35.google.com with SMTP id 586e51a60fabf-29fe83208a4so793687fac.0 for ; Thu, 09 Jan 2025 20:14:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736482467; x=1737087267; darn=freebsd.org; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=KnsLpyt6OxUYDRAaoDTbtI1iJd3C7/LRrcl60NaN7Oo=; b=OUBMzuf/mPSKoVVwjnjFQL3w12F+3/i1gOZho10MCICRE0s6nWElFBDtp11c4RjMYq 5grOpfZWOP+u0ThODUVUawZXpXb/nqxFz7k2UVPmaPAUUlqnSoMjtdGzvk8Qe5G6SBjm 8/E3QZ0gxq60eaKKB4vgTcny0D0dXTv3qnJuoWZR+16ELD9gIg6LXYQWJpj2UjKOPaCV AOay4WD2P66tFhS/uspt1irFAA/qmyFVYbqhXWm87EeZ8peRh/j2Tca4bpC28gjg6hZ7 UWFUB5gnPbRHY1AWkO7l/+WVrq9rdNXSbeIkwcGUGbHbBk5ZssDau42ypSPeT6G7omEr X9Qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736482467; x=1737087267; h=content-transfer-encoding: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=KnsLpyt6OxUYDRAaoDTbtI1iJd3C7/LRrcl60NaN7Oo=; b=RSxno/kacyDqxSf61OhfTyqh7FybA846U2k2o7RfbCEOQJwbelKpHME6Rtbk0VUF/O 7vIj7Y02ze0UfvVjs1M1kknEwv7xqOnn6z9JO1+fjAFuwrRzatcj/hQqM4rbUOJWoW/G JM0t/TsUOUqf4PJzHEV5qGnVAddOM+CYrIzgOzmmgDR6Sv6WAoRjt60hM2UVHLsKCQEk e/GPIXxGLbGg1Br4bXUFamWJot/ljGrGAbk5dCPOyj+/0tfM01RbqeX7uAZS8sBz92oI L0c8yOeEojY98QjDgVyo/uTDHuI2LJtbt14gAukxsR2vR2SiSy415BXhVBsJiJSxbyuu e1gQ== X-Gm-Message-State: AOJu0Yw8dvFmCR+obvpKAoRmYRcLyQIGsbxIqMGS49T6IDU5souvGH77 MO0kcP83EKG72VXPi+9xKi7speij8+Wx4zAA7CGGEnID87oUcX4Gt2MMuJxWAONpNu8+fHM8QnA tEFIrjiaCDKJ8Zx95Ggl5heuQm08sfw== X-Gm-Gg: ASbGncst6oEUer6WYHfJTLEplXh14O0sGcLKJXjLb8S/avMjnKbqEY9LWzx+gtP+dwd iU6ltVB5EeWscarhr123tCI6IADCl3FMjEn3NbSs= X-Google-Smtp-Source: AGHT+IFBU12bNPSj5N/K3EVaCpB2kurtW7E19tL4Hwo+Ogm0XRTHZgw/W9p/axQQJcVfwUYA9do5mWMR8hDC4iUsKBQ= X-Received: by 2002:a05:6871:71c5:b0:2a7:8b78:e902 with SMTP id 586e51a60fabf-2ad807922d0mr2509782fac.7.1736482467096; Thu, 09 Jan 2025 20:14:27 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 References: In-Reply-To: From: Dan Shelton Date: Fri, 10 Jan 2025 05:13:50 +0100 X-Gm-Features: AbW1kvbzZNTrbnmvKnsI4JJ9R7jFZUNRylCrqeH0pH7-bdK9OtHcPvOFsZx2IXs Message-ID: Subject: Re: WRITE_SAME support in FreeBSD nfsd NFSv4.1 mode? To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4YTpFc6ryHz4XlH X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.99 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.994]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2001:4860:4000::/36:c]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_FROM(0.00)[gmail.com]; RCPT_COUNT_ONE(0.00)[1]; FREEMAIL_ENVFROM(0.00)[gmail.com]; TAGGED_FROM(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; MISSING_XM_UA(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; ASN(0.00)[asn:15169, ipnet:2001:4860:4864::/48, country:US]; MID_RHS_MATCH_FROMTLD(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; RCVD_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2001:4860:4864:20::35:from] On Fri, 10 Jan 2025 at 02:59, Rick Macklem wrote: > > On Thu, Jan 9, 2025 at 4:31=E2=80=AFPM Dan Shelton wrote: > > > > Hello! > > > > Does FreeBSD nfsd support the WRITE_SAME request in NFSv4.1 mode? > Not at this time, I'm afraid. > > Maybe in a future release, rick How fast could it be implemented? Dan --=20 Dan Shelton - Cluster Specialist Win/Lin/Bsd From nobody Fri Jan 10 14:57:34 2025 X-Original-To: freebsd-hackers@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 4YV4X36l2Yz5kSnm for ; Fri, 10 Jan 2025 14:57:55 +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 4YV4X30tH1z4tND for ; Fri, 10 Jan 2025 14:57:55 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=JO41IfOH; 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; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-ed1-x52b.google.com with SMTP id 4fb4d7f45d1cf-5d3d479b1e6so2840453a12.2 for ; Fri, 10 Jan 2025 06:57:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736521073; x=1737125873; 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=Y5pWoivjys7/vQEf5zmjIIbG5yrVtlDk84lnnuFFkoY=; b=JO41IfOH3BiJd258ccQjjicKDSTt1+sO+q6tLOah9nO1Hf+ye6h7MSu85iXPq15VMX P7r4/Pb4k8jo2iG8jqYQYqtGTKcvVh8la79doDHWv6yiQ9XcRFXAj7cTW5lYNG0ltflZ 6WnAGdP9l82THyGMGZG5tgtvDPAIT/DnplnVQTSlF0clxJPgFbxw7sfWxBgsx+saSdo5 iXi6iFntBO75p5BJCZZR3tfghngjRO5W1EY84PTHZtapzJ6904Fs03w8iOGNBhSQERbV 9PFA16n1w/72Hv7G5GocPBeE+79Ants4Ojr7xEfpLnN5H5y9wKx25aSyKXtR3NHQC7Rj LqZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736521073; x=1737125873; 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=Y5pWoivjys7/vQEf5zmjIIbG5yrVtlDk84lnnuFFkoY=; b=A5Lc7kPDSQJhxxHq+fKwFrUmooS5W7cwtFEy6RIx8PW+aKYNQJBk7li9r8aU8iqcKE e7RO12Aq6VDtZcBl8/0JN3l9KAxG0M+gZFY/ajKQVGjzGPBHZm4krALpTBzuozgaBaCr DRjb3iEokwCjIld/OgtH+U1fQWUXkWWE5dJqYlwf6Qyl+4zn9ifqy99SboyjcBeeTyJW FIaI1ioIg9ms68ZryGAqBoKOs0O6NPj9tgAbPYz2Nx6Tb9PBp4AL3BdWUWTMP0UAw3UM 9r9e0DGZPpKm9Lzoulep95RVfXGaKjIodiIGc/kVruJWDHh3yzlt2TG60SiiM2y8gjCb RMWQ== X-Gm-Message-State: AOJu0Yy7eE+r51RC7q21JU1iLVHBaH4kcei4GqyPZCv3gsYeybYDJ4HG wslLEbEeBver2e5coOGfJrxbWUibfSs3+WpaTDOlCQ0CLP7ppw0NeYreP3YAoHwHs0reR4JOI85 Ze9OmtsDWBllc8BtKW35xPmzvQZXD X-Gm-Gg: ASbGncv4leoC60mEgJ7+ytekTiVRzRuLl6DRJ9bWAm+jRKpDGo6aqwIwKE418ONn9kT AcLybWhmX88fx7rGt2Er5WzcDyHfS4DHqW976/dECGrPurFuSJ1+S9hI8PuYlnE+LPgKo X-Google-Smtp-Source: AGHT+IFscKGhEci0QNrEF7N1ppgstP95M3RreKZXN7haqUxEKSN7KvOUa0BANy36HkiwuU8W9nFC0zh4fkU07R3KNyQ= X-Received: by 2002:a50:858c:0:b0:5d9:857e:b259 with SMTP id 4fb4d7f45d1cf-5d9857eb31cmr13258035a12.31.1736521073084; Fri, 10 Jan 2025 06:57:53 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 References: In-Reply-To: From: Rick Macklem Date: Fri, 10 Jan 2025 06:57:34 -0800 X-Gm-Features: AbW1kvabYbl1oosly5P1xEfmuNywSWMMGzL8JMFdAnKEk7qawu8htjdCynhRv8o Message-ID: Subject: Re: WRITE_SAME support in FreeBSD nfsd NFSv4.1 mode? To: Dan Shelton Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4YV4X30tH1z4tND X-Spamd-Bar: -- X-Spamd-Result: default: False [-3.00 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; 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)[]; RCPT_COUNT_TWO(0.00)[2]; FREEMAIL_FROM(0.00)[gmail.com]; FREEMAIL_TO(0.00)[gmail.com]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; TAGGED_FROM(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; MISSING_XM_UA(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; MLMMJ_DEST(0.00)[freebsd-hackers@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]; TAGGED_RCPT(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::52b:from] On Thu, Jan 9, 2025 at 8:14=E2=80=AFPM Dan Shelton wrote: > > On Fri, 10 Jan 2025 at 02:59, Rick Macklem wrote= : > > > > On Thu, Jan 9, 2025 at 4:31=E2=80=AFPM Dan Shelton wrote: > > > > > > Hello! > > > > > > Does FreeBSD nfsd support the WRITE_SAME request in NFSv4.1 mode? > > Not at this time, I'm afraid. > > > > Maybe in a future release, rick > > How fast could it be implemented? For the simplest version, not too long. The simplest version would be synchronous only and use VOP_WRITE() calls. Doing a new VOP_xxx() call to try and optimize it per-fs would take quite a bit longer. (I know very little about ZFS, but= just maybe, block cloning would be useful for this?) Btw, it is a NFSv4.2 call, so it would only be supported for NFSv4.2 and no= t NFSv4.1. rick > > Dan > -- > Dan Shelton - Cluster Specialist Win/Lin/Bsd > From nobody Fri Jan 10 15:01:47 2025 X-Original-To: freebsd-hackers@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 4YV4cn5S4sz5kT2Y for ; Fri, 10 Jan 2025 15:02:01 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-ed1-f47.google.com (mail-ed1-f47.google.com [209.85.208.47]) (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 4YV4cm6Wbpz4vcF for ; Fri, 10 Jan 2025 15:02:00 +0000 (UTC) (envelope-from asomers@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.208.47 as permitted sender) smtp.mailfrom=asomers@gmail.com; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=freebsd.org (policy=none) Received: by mail-ed1-f47.google.com with SMTP id 4fb4d7f45d1cf-5d3cf094768so3703438a12.0 for ; Fri, 10 Jan 2025 07:02:00 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736521319; x=1737126119; 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=uqivsgjmYJ+/V5+hIpiHQULIA5MwGt0ZJZ3MCBNeapM=; b=PP0uDPD+kHthpXbUZDf4+mD/3+BVGVasw5P+X4QGTJ3X4YH9o0YEUu/GJ02SyvWb9Q Wj1ZLECPCwqFiPxXahpyao+GpUdakVYBgai3zZeBbReilktJWxtkbotRyOdWURYBCAed 297SUNT0Khifw6RuYZSDRUx81EDkiGG5L+t4Do7XGl19pRyu+L6+CI9i0BgPMrB8iS7u emLqMV2PbG0rNJ9Dycyb/h7dVtz/sMOJvlbhXkietWAjXl7ssvrNWuuqSL3ifjfHNp+v /PMhebDvEIkaR2daW1qZkh/0Oecuu6GZtxiA3O1IA/VlaFfDeEsvDZImctY8dQdYiirZ 6tQQ== X-Gm-Message-State: AOJu0Yz2qQCH9V3oDwg6gMmtV3YSnR3LxpBmKK8PG7jmRO46tt48CHxd /n9BPGRj4Nptx/u2yrlJ6Rtzvq2SyDUBum7/PhmQhQ25KsK2WVldTTXiGMIYvXFHnfkRiUWC0Fu 6xHv9dtPnG6NhuRGTLguRBMkYeRH2JA== X-Gm-Gg: ASbGnctmJUJVxb/w/GBgC9ys/LZQlIrJW6KK11+SkxrVAk1e2ye65OtAVCIyJD7W0mx /SuXIme9a6pXc9atXmmZijtG5CR0T7H44D4ScLw== X-Google-Smtp-Source: AGHT+IFLRO4iPWrohz4RM3oE6R40XJ8jk/ZLY4xWiiwn85GpRUpffWS+AAUL9LFpuQG+zNQ0cnJ4ChgUN+ztbDKqLx4= X-Received: by 2002:a05:6402:270d:b0:5d4:35c7:cd7c with SMTP id 4fb4d7f45d1cf-5d972e4cb92mr8359521a12.26.1736521319143; Fri, 10 Jan 2025 07:01:59 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 References: In-Reply-To: From: Alan Somers Date: Fri, 10 Jan 2025 08:01:47 -0700 X-Gm-Features: AbW1kvZ6PH3PdHB2CXXJii1Yj1q-PlKOJGKax7_QDtzZjVcTph2CFw7ferXlLXs Message-ID: Subject: Re: WRITE_SAME support in FreeBSD nfsd NFSv4.1 mode? To: Dan Shelton Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4YV4cm6Wbpz4vcF X-Spamd-Bar: - X-Spamd-Result: default: False [-1.89 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; NEURAL_HAM_MEDIUM(-0.99)[-0.994]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; MIME_GOOD(-0.10)[text/plain]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : SPF not aligned (relaxed), No valid DKIM,none]; RCPT_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; MISSING_XM_UA(0.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FREEFALL_USER(0.00)[asomers]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; RCVD_COUNT_ONE(0.00)[1]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.208.47:from]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; TAGGED_RCPT(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[209.85.208.47:from] On Thu, Jan 9, 2025 at 5:31=E2=80=AFPM Dan Shelton wrote: > > Hello! > > Does FreeBSD nfsd support the WRITE_SAME request in NFSv4.1 mode? > > Dan > -- > Dan Shelton - Cluster Specialist Win/Lin/Bsd Out of curiosity, what is your use case? From nobody Fri Jan 10 15:31:32 2025 X-Original-To: freebsd-hackers@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 4YV5HD5Kwbz5kWgd for ; Fri, 10 Jan 2025 15:31:52 +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 4YV5HD39bwz55m5; Fri, 10 Jan 2025 15:31:52 +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-5d982bce8f9so3985155a12.1; Fri, 10 Jan 2025 07:31:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736523110; x=1737127910; 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=BB8mFyoB6wRhYMXbiBcg9iMSXoQffDdqUYNovtOw204=; b=j34PeGUikRlW0Mj4cYBq18ZJC2ZM6Wbi2HpYfdom67hs0axUffFhbeptjvJKbyO8DK ewbwKrK4f9ewiPTjZaI8QED9+MCDmCikMN3eWCjl2KIzW2yA/ndgcHsGhHC9YUndEt+S PuBPxiqciECRZDaehKXvXLquZMSZI7vKhD2++J2eRnXHQdLNUaoihsHJYqEFTclDb1R3 FzJCnRI/n1Lw+8KwmI2octso9kivV6j9VwYQiUL7Cvp6nnt8fXUdGKU228I15dGXeJY2 pgAJyKT6dflYgv8fXjJZmtCFia+lfy6NZxw0aAo51laK5T96d0yYnaWqLLyT87gZHGku /WDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736523110; x=1737127910; 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=BB8mFyoB6wRhYMXbiBcg9iMSXoQffDdqUYNovtOw204=; b=M2CGTOEPoGvsfc9MSH0022r5SzSq770pfwp0M4rtP62RU0bQTkdomJbEOe+sj55qox 6wOHgk19qahhbATlMkZyY6Ewi+zBhvzdo/aFzhuIikXtBEXhH/f6jvrcMPY19ie+BHnk P+pDsDpNEw/bJkGO89RKu+3WD4mdCnZ7mVPGQrA0GjtcpdZ39jaYz9qllVOQSOda1/nJ C1LPaHfuYF2U4MeswGWOEIzxDkyFASG3INoMrbnQqSIaqO1ovgpIhj7UqB0V4xKMiqOZ iKBW3ZpkFBpBgbm/83ifC7sjwXFV3Rhsl6SOhgIhFShCiS98cC7PNJ5bH7VxgWy4qtOg GEiA== X-Forwarded-Encrypted: i=1; AJvYcCVRyq3KFflniHMfvz3P50gUzOY56kGN/iiqBLp5HqU5c7WOkUJwLYck29kSLgaY1Qm9Hf8wWYDRKSWQKfDt0e0=@freebsd.org X-Gm-Message-State: AOJu0Yx0lp9Ev2X3Ewm908N4RJrKy1HqHbwmF2x7tujhJYT1xGBol/9Y rjOKt51jK/4002IAfhil7dfc9m+8rC1VkCmVpUItTw9IoD4S291xWnYrXFdK92ULI7lSmjRUQtP KSH7rujamtwkW2ejSNSprwI/WbyEN X-Gm-Gg: ASbGncuFD47WDAUA58zBMuivUJJK5rIL0SNzygxFYrHn9UHX2ghxqdCjcUfAzGiCdxL yPibwav4cAY15+ZROYSMyWQp9mqk8phCmKQbyYfo0eq67JaUFrlGONOgSTSFxp+89hWqeedw= X-Google-Smtp-Source: AGHT+IEoJbI0u9F/eyowjk94baLrmoonarF6DXXLV2GEbn5kcRkq8ZSLG9WrdSFDRbbengLOXYausjKU2dgITqWtioM= X-Received: by 2002:a05:6402:274c:b0:5d3:e766:6143 with SMTP id 4fb4d7f45d1cf-5d972e7247cmr10741895a12.30.1736523109810; Fri, 10 Jan 2025 07:31:49 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 References: In-Reply-To: From: Rick Macklem Date: Fri, 10 Jan 2025 07:31:32 -0800 X-Gm-Features: AbW1kvbjjICg_AfrRq9wkZ0Dnhphw-g_V8bvHJJF7lqAxzKzPnT4QUQB8N4vCCI Message-ID: Subject: Re: WRITE_SAME support in FreeBSD nfsd NFSv4.1 mode? To: Alan Somers Cc: Dan Shelton , freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4YV5HD39bwz55m5 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[]; TAGGED_RCPT(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] On Fri, Jan 10, 2025 at 7:02=E2=80=AFAM Alan Somers w= rote: > > On Thu, Jan 9, 2025 at 5:31=E2=80=AFPM Dan Shelton wrote: > > > > Hello! > > > > Does FreeBSD nfsd support the WRITE_SAME request in NFSv4.1 mode? Just fyi for other readers... A normal NFSv4.2 write pushes the data down the wire to the server. A WRITE= _SAME pushes a description of a data block and a repetition count down the wire to the server, allowing a lot of repetitive data to be written without sending it all down the wire (at least that is my understanding;-). I am not aware of any system call for this at this time, although there is active discussion of this on the Linux NFS mailing list. rick > > > > Dan > > -- > > Dan Shelton - Cluster Specialist Win/Lin/Bsd > > Out of curiosity, what is your use case? > From nobody Fri Jan 10 16:17:19 2025 X-Original-To: freebsd-hackers@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 4YV6Hx4xFQz5kb35 for ; Fri, 10 Jan 2025 16:17:33 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com [IPv6:2607:f8b0:4864:20::102d]) (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 4YV6Hx0Hxkz3xQ6 for ; Fri, 10 Jan 2025 16:17:32 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20230601.gappssmtp.com header.s=20230601 header.b=XxchnTlB; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::102d) smtp.mailfrom=wlosh@bsdimp.com; dmarc=none Received: by mail-pj1-x102d.google.com with SMTP id 98e67ed59e1d1-2ee50ffcf14so5152705a91.0 for ; Fri, 10 Jan 2025 08:17:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1736525851; x=1737130651; 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=PUhTF3XcyGSPrgbYkWy0AdEDTEcKZmlI+x4U7XZqm8E=; b=XxchnTlB2OILgFdY2n0sTSVjfIyB0QzdgLok91O4Gvx70u5rGbWJNUdDnCn11qsFnX ZMiOxd0a56wVtdaVNYk1GNp/JLOZr5+EiHTbtL6uvWC55Z2HuI1BeGjM0V9KTRhqYFM9 LcHJkQk8K6NUVH1Yyn6aT6RFzkTuVMvyjoKj+/3dVsNGd6iwBUUh88B6z3xxQYue6RE4 fIbX96VBNdBJFDyuj/Ogb/6Do3XlSWGulvqGzC0wJt5/miy8nwXGmo1K7VTyd9Uk7pfb SPDyPjCfwvo7v2RnK2lVxB6x603SYbEO+gXzBsg1uEsKsI3tEn85Phljhd0MFjuKB23k roNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736525851; x=1737130651; 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=PUhTF3XcyGSPrgbYkWy0AdEDTEcKZmlI+x4U7XZqm8E=; b=RPLro3AwFHja8dnDei8SuKAZMIZFVE2J87KqXgGH0woSUDhj2CeJEWN55b4pXrPR3y zuDEFwuqagCMz4YztZPeUcBJPEl2DBKYWLmA0f6EgJDfEsqqleSm4au3Omuo21UPcHpX 51W59dkUHGCIqVoVxdtQDYOijY//gmEJg03eILD+V2/sR+5cLp0hSTXhY4vJZPkXofMO JDZxVSicbhcnX8dJvQzOXNvCBEW95JgWcIEBGHbofkoSMDWFKOMBsPQMuYZ+S9B4SUjZ 782Mn21jmwGMFCzS0/GrP/GA6hXyDMaWpZA8ctZR1JXghvBWjzqh0HNIdn6iNhhXTGDk 8lNw== X-Forwarded-Encrypted: i=1; AJvYcCUvJoebgMgAEFKRajyPR7Gyo9oCwdFqcxfKGKoCt42DVi32MlTF/6Q9Xl5p30ePR2N/hsmLofEsM45lT09VR94=@freebsd.org X-Gm-Message-State: AOJu0Yw/B14xjUPeH6H1kEPt6lWnExgCMrHzf3G/KcIc43NFXLEFAUjf /ZtxZxqsa3oe843hsr8p/tv2VFv4IN3Huo6UKZp4vGQU+GBqwwYGVmkSpOU1E+qVdMcqaD4OemR bQhhs/Nr8e23t7E6DU9NJMPhXqvkXJa5tFGU1KVuClrdrUghaUsA= X-Gm-Gg: ASbGncuZw8bfg2jggbX+dllTJFrGBpZPdgF1V4NI8tLP7qzIZimSrHkLoKbYgQL/2bk SHBd7SH2tTMQ6azkErSAF1pSZcCfhiqXPpdqG1A== X-Google-Smtp-Source: AGHT+IHsg4c+R1xnRMcukpFOwljg2wiwJh+VU962z5bhJNtWYYGJ5ASusiqsKCgj2oOyBkwL3hUy7i0iFcpZCeGayuE= X-Received: by 2002:a17:90b:2705:b0:2ee:5c9b:35c0 with SMTP id 98e67ed59e1d1-2f55836a9c8mr9428648a91.9.1736525851129; Fri, 10 Jan 2025 08:17:31 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Fri, 10 Jan 2025 09:17:19 -0700 X-Gm-Features: AbW1kvZaiDpgGvNv6_YFZ69N3MjbpkMnvSrxX3iXF7yIcjoZWWC7lz6qoRL6fyA Message-ID: Subject: Re: WRITE_SAME support in FreeBSD nfsd NFSv4.1 mode? To: Rick Macklem Cc: Dan Shelton , freebsd-hackers@freebsd.org Content-Type: multipart/alternative; boundary="0000000000008017d4062b5c6e56" X-Rspamd-Queue-Id: 4YV6Hx0Hxkz3xQ6 X-Spamd-Bar: - X-Spamd-Result: default: False [-1.99 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.993]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20230601.gappssmtp.com:s=20230601]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; DKIM_TRACE(0.00)[bsdimp-com.20230601.gappssmtp.com:+]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org]; FREEMAIL_TO(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; DMARC_NA(0.00)[bsdimp.com]; ARC_NA(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_NA(0.00)[no SPF record]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; FROM_HAS_DN(0.00)[]; MISSING_XM_UA(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TAGGED_RCPT(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::102d:from] --0000000000008017d4062b5c6e56 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Jan 10, 2025 at 7:58=E2=80=AFAM Rick Macklem wrote: > On Thu, Jan 9, 2025 at 8:14=E2=80=AFPM Dan Shelton > wrote: > > > > On Fri, 10 Jan 2025 at 02:59, Rick Macklem > wrote: > > > > > > On Thu, Jan 9, 2025 at 4:31=E2=80=AFPM Dan Shelton > wrote: > > > > > > > > Hello! > > > > > > > > Does FreeBSD nfsd support the WRITE_SAME request in NFSv4.1 mode? > > > Not at this time, I'm afraid. > > > > > > Maybe in a future release, rick > > > > How fast could it be implemented? > For the simplest version, not too long. > The simplest version would be synchronous only and use > VOP_WRITE() calls. Doing a new VOP_xxx() call to try and optimize > it per-fs would take quite a bit longer. (I know very little about ZFS, > but just > maybe, block cloning would be useful for this?) > I had discussions years ago about adding a BIO_WRITE_SAME and whether or not it made sense. It's mildly helpful to just send one write command that writes all the LBAs using the SCSI WRITE SAME command. But it got hairy in a hurry and WRITE SAME is mostly only used to unmap / trim blocks anyway. But only SCSI drives support this, and it's been too long to recall if they all support writing multiple blocks from the same OUT BUFFER or not. NVME doesn't have a similar concept (just write zeros), so I gave up on it. I didn't have a good use case for it. Warner > Btw, it is a NFSv4.2 call, so it would only be supported for NFSv4.2 and > not > NFSv4.1. > > rick > > > > > Dan > > -- > > Dan Shelton - Cluster Specialist Win/Lin/Bsd > > > > --0000000000008017d4062b5c6e56 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Jan 10,= 2025 at 7:58=E2=80=AFAM Rick Macklem <rick.macklem@gmail.com> wrote:
On Thu, Jan 9, 2025 at 8:14=E2=80=AFPM Dan= Shelton <d= an.f.shelton@gmail.com> wrote:
>
> On Fri, 10 Jan 2025 at 02:59, Rick Macklem <rick.macklem@gmail.com> wrote:<= br> > >
> > On Thu, Jan 9, 2025 at 4:31=E2=80=AFPM Dan Shelton <dan.f.shelton@gmail.com<= /a>> wrote:
> > >
> > > Hello!
> > >
> > > Does FreeBSD nfsd support the WRITE_SAME request in NFSv4.1 = mode?
> > Not at this time, I'm afraid.
> >
> > Maybe in a future release, rick
>
> How fast could it be implemented?
For the simplest version, not too long.
The simplest version would be synchronous only and use
VOP_WRITE() calls. Doing a new VOP_xxx() call to try and optimize
it per-fs would take quite a bit longer. (I know very little about ZFS, but= just
maybe, block cloning would be useful for this?)
--0000000000008017d4062b5c6e56-- From nobody Fri Jan 10 23:24:42 2025 X-Original-To: freebsd-hackers@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 4YVHnC6XgFz5kmhL for ; Fri, 10 Jan 2025 23:25:03 +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 4YVHnC03rGz4t6K for ; Fri, 10 Jan 2025 23:25:03 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=YTS8K27M; 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; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-ed1-x532.google.com with SMTP id 4fb4d7f45d1cf-5d3e6274015so4126222a12.0 for ; Fri, 10 Jan 2025 15:25:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736551501; x=1737156301; 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=nxsI6SHcSRMSvzybCTSOVFx/1K3Fi6s2nCquzMQxXVA=; b=YTS8K27MzSdDzRZtFozdS6zJSs+KLtkVg9ItsQISnF9j5/NSTgZY69pAUyEbNkDsyC 2kshf8794yzSlFSVd+aQYb3JKurTCw7bAXApedzYBtnsi8/srWi0/DD3ss5eyAmfyu6J eZBGSK5skQvvLlONtNrXEjT8AZzhynxEq/EIMj08F+E1KwAZgvouyRKG/cCQOqD1hHkv zbSPhtkWmC0lP2ypiEfoTp4pYVqsnCMbSP82w96C09HUahzAq02AkL23CYx2IRU6vKHU iC3UfJVDYyRce4kIUP1flaz4FKGbLdyRZi/73i6pp6QT/VuheYoZzBRqXNAIfK6IcBij a76A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736551501; x=1737156301; 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=nxsI6SHcSRMSvzybCTSOVFx/1K3Fi6s2nCquzMQxXVA=; b=gmv9CHwhxOSkHUv6gywBfuftJu1QoORjHDUSxcxH+LZDsj5VW33v6xAZnoy16SWJRZ 5a9/8H3qpw7e4dZ+xK8Vgt5yTSf0i9kRyaxNC2yejB/o1svYOTKzmccHyw4fL7aBAO0w T70Xjr3O0/QGiHqV2fMwmvQzPZiZcFN6GEc2cQ+cXeTJmiaRbW2gVIA1FkXfCv+J/1Yb YvN9/nUWQhr+Vz853+MURAC4NbmJycXfpboLzldiDFUTeltBaX3LK/BeKKIEm5yxe6ff UDe+KEJX3WXgwGJb9uR/l+o8LMGLQJuZzSIsJGh2LUxESaHFTS0mynLiM2KP9YYvNM6n khUw== X-Gm-Message-State: AOJu0Ywt9Ap7Fj5APWPiOpUTGvgQM0FQCKeLoCSXuuHw+C4VD4xVwnQ6 y6lfLQ2NQOUoLJoMPuzkcZZIeKiVrE6ic+ylNe2+Pij86Qm/gtae/RAlqeW0ma+0hOnNu17yVUZ 0I6M6CMSNcKYxSlpcWRI0YbGkDrkP X-Gm-Gg: ASbGncv2+SQCwl6n5j/ArsO1+mUMzzCVZ95rqmi1EUvuq2AUiiGw1OMRK0IdB9y93oq xetDWFig9ONnb64vCwAAitOfsn7/b0OxR9fXGofyebuoJETXM2fjLcxJmxGLOkcfTc8L0ejc= X-Google-Smtp-Source: AGHT+IFpHOCGjnaBkgmLxOtOesKjW+7W5IKc7/P8A916phKJ0smPCBhCNQ4HNX0FEwHxz9IZIL5fC9qhqkb4N6uFc6o= X-Received: by 2002:a05:6402:2345:b0:5d0:b51c:8479 with SMTP id 4fb4d7f45d1cf-5d972e0a087mr12088443a12.10.1736551500722; Fri, 10 Jan 2025 15:25:00 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 References: In-Reply-To: From: Rick Macklem Date: Fri, 10 Jan 2025 15:24:42 -0800 X-Gm-Features: AbW1kvbhzG3yh9uRoS4WlHRtSjEd5QUvsaiXQk9MQEROOX_zk5REM7ClptJJfKw Message-ID: Subject: Re: WRITE_SAME support in FreeBSD nfsd NFSv4.1 mode? To: Dan Shelton Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4YVHnC03rGz4t6K X-Spamd-Bar: -- X-Spamd-Result: default: False [-3.00 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; 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]; FREEMAIL_TO(0.00)[gmail.com]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; TAGGED_FROM(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; MISSING_XM_UA(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; MLMMJ_DEST(0.00)[freebsd-hackers@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]; TAGGED_RCPT(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::532:from] On Thu, Jan 9, 2025 at 8:14=E2=80=AFPM Dan Shelton wrote: > > On Fri, 10 Jan 2025 at 02:59, Rick Macklem wrote= : > > > > On Thu, Jan 9, 2025 at 4:31=E2=80=AFPM Dan Shelton wrote: > > > > > > Hello! > > > > > > Does FreeBSD nfsd support the WRITE_SAME request in NFSv4.1 mode? > > Not at this time, I'm afraid. > > > > Maybe in a future release, rick > > How fast could it be implemented? I will probably try to come up with at least a proof of concept patch soon. Once I have that much, I can start to think of what a VOP_WRITESAME() might look like. If possible, it would be nice to get this in 15, since it = would have to wait for 16 otherwise. Dan, if you could create a bugzilla PR (bugs.freebsd.org) asking for this a= s a new feature, at least it won't get completely forgotten and I can hang patc= hes there. You could look at the release schedule for FreeBSD 15 to see what the optimistic bound on an implementation of this is. rick ps: If you can discuss it, I would also like to hear something about the use case. This can help justify the work. > > Dan > -- > Dan Shelton - Cluster Specialist Win/Lin/Bsd > From nobody Sat Jan 11 04:11:06 2025 X-Original-To: freebsd-hackers@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 4YVRLs6wd7z5lGYk for ; Sat, 11 Jan 2025 05:06:13 +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 4YVRLp684jz4fCw; Sat, 11 Jan 2025 05:06:10 +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=VWZuRmqz; 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; dmarc=pass (policy=none) header.from=dec.sakura.ne.jp Received: from kalamity.joker.local (124-18-43-234.area1a.commufa.jp [124.18.43.234]) (authenticated bits=0) by www121.sakura.ne.jp (8.17.1/8.17.1/[SAKURA-WEB]/20201212) with ESMTPA id 50B4B6kJ086444; Sat, 11 Jan 2025 13:11:08 +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=1736568668; bh=BvBH9PpTJzunYp3IKQ3rkyQjrbuzr7LsQgsNUhceruA=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=VWZuRmqzR2Vr9lplmaN+N+EJMaroIWHdKFxQeevSRqfFTr2opJ9sl0R4tBazwo1J2 mtSp0xJFuXQcqtLgunUYHhQFhJsF4w/yIM37ZGB4vcIPAPiQ9JPEXunVHnFMDPC76e GXa3AVU31aqYO1pK16dtuXEmUo95OLa4hCcn97tc= Date: Sat, 11 Jan 2025 13:11:06 +0900 From: Tomoaki AOKI To: Mark Johnston Cc: Konstantin Belousov , freebsd-hackers@freebsd.org Subject: Re: widening ticks Message-Id: <20250111131106.4d2657de20eeed7eef5c0b15@dec.sakura.ne.jp> In-Reply-To: References: Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.2) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4YVRLp684jz4fCw X-Spamd-Bar: ++ X-Spamd-Result: default: False [2.29 / 15.00]; URIBL_RED(3.50)[dec.sakura.ne.jp:dkim]; SUSPICIOUS_URL_IN_SUSPICIOUS_MESSAGE(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.91)[-0.908]; MV_CASE(0.50)[]; BAD_REP_POLICIES(0.10)[]; MIME_GOOD(-0.10)[text/plain]; ONCE_RECEIVED(0.10)[]; HAS_ANON_DOMAIN(0.10)[]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; R_DKIM_ALLOW(0.00)[dec.sakura.ne.jp:s=s2405]; HAS_ORG_HEADER(0.00)[]; DMARC_POLICY_ALLOW(0.00)[dec.sakura.ne.jp,none]; ARC_NA(0.00)[]; GREYLIST(0.00)[pass,body]; DKIM_TRACE(0.00)[dec.sakura.ne.jp:+]; RCVD_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MID_RHS_MATCH_FROM(0.00)[]; R_SPF_ALLOW(0.00)[+ip4:153.125.133.16/28:c]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP]; TO_DN_SOME(0.00)[] On Wed, 8 Jan 2025 18:07:47 -0500 Mark Johnston wrote: > On Thu, Jan 09, 2025 at 12:18:48AM +0200, Konstantin Belousov wrote: > > On Wed, Jan 08, 2025 at 04:31:16PM -0500, Mark Johnston wrote: > > > The global "ticks" variable counts hardclock ticks, it's widely used in > > > the kernel for low-precision timekeeping. The linuxkpi provides a very > > > similar variable, "jiffies", but there's an incompatibility: the former > > > is a signed int and the latter is an unsigned long. It's not > > > particularly easy to paper over this difference, which has been > > > responsible for some nasty bugs, and modifying drivers to store the > > > jiffies value in a signed int is error-prone and a maintenance burden > > > that the linuxkpi is supposed to avoid. > > > > > > It would be nice to provide a compatible implementation of jiffies. I > > > can see a few approaches: > > > - Define a 64-bit ticks variable, say ticks64, and make hardclock() > > > update both ticks and ticks64. Then #define jiffies ticks64 on 64-bit > > > platforms. This is the simplest to implement, but it adds extra work > > > to hardclock() and is somewhat ugly. > > > - Make ticks an int64_t or a long and convert our native code > > > accordingly. This is cleaner but requires a lot of auditing to avoid > > > introducing bugs, though perhaps some code could be left unmodified, > > > implicitly truncating the value to an int. For example I think > > > sched_pctcpu_update() is fine. I've gotten an amd64 kernel to compile > > > and boot with this change, but it's hard to be confident in it. This > > > approach also has the potential downside of bloating structures that > > > store a ticks value, and it can't be MFCed. > > > - Introduce a 64-bit ticks variable, ticks64, and > > > #define ticks ((int)ticks64). This requires renaming any struct > > > fields and local vars named "ticks", of which there's a decent number, > > > but that can be done fairly mechanically. > > > > > > Is there another solution which avoids these pitfalls? If not, should > > > we go ahead with one of these approaches? If so, which one? > > > > You cannot do this in C, but can in asm: > > .data > > .globl ticksl, ticks > > .type ticksl, @object > > .type ticks, @object > > ticksl: .quad > > .size ticksl, 8 > > ticks =ticksl /* for little-endian */ > > /* ticks =ticksl + 4 for big-endian */ > > .size ticks, 4 > > > > > > Then update only ticksl in the hardclock(). > > I implemented your suggestion here: https://reviews.freebsd.org/D48383 As this is already committed to main, commenting here instead of review D48383. Maybe I'm too paranoid and overlooking something, but... *If "jiffies" in LinuxKPI is really unsigned, isn't there any possibilities that relies on its value to be larger than 0x7fffffffffffffff as a threshold? (Yes, it should be silly and non-realistic, but theoretically possible.) *Is anywhere checking carry (sign) bit for int on LP32? Maybe it would be the reason if "jiffies" in LinuxKPI is really unsigned. Regards. -- Tomoaki AOKI From nobody Sat Jan 11 16:34:06 2025 X-Original-To: freebsd-hackers@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 4YVkch0TGfz5kYtK for ; Sat, 11 Jan 2025 16:34:12 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (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 4YVkcg3KP4z4n7L for ; Sat, 11 Jan 2025 16:34:11 +0000 (UTC) (envelope-from markjdb@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-qk1-x733.google.com with SMTP id af79cd13be357-7b6e9db19c8so250737685a.3 for ; Sat, 11 Jan 2025 08:34:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736613250; x=1737218050; darn=freebsd.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:from:to:cc:subject:date:message-id :reply-to; bh=xgsBGy2hT+MhlSwkusN4HAkDmMzVEX+YUiRisETZSHc=; b=FHrUMPf6sdVft5Fosy3lPm+Fvsow2TRvv9JW13+5ZIPa+gUN4gdbPxKo65LNks5WuT TzuMUud81YmNtmsVTQ/jIfADiyUbv6twcHHk7D42XP8phwz2MM8bMmSmqgrmwboQffK6 KPQLrLa2vnFcqPaeXdmGTAiqVAaBoTFhAEzch5IjgKCEABdnbFWr5ggPOBZlR2W5+Cz0 NYjsH3bYsFMGvUEYSLydi/IL58+xCNK0EDiuqrZy3DEh+2Ulttzvi5ManEmbYpzP8eFr LtHlKMqixXAJ+CYhYwoM88/pVAlh05b+24DZBIhXiyDSaYfWm14nF7KZzJygivGyzYLI Sehg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736613250; x=1737218050; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=xgsBGy2hT+MhlSwkusN4HAkDmMzVEX+YUiRisETZSHc=; b=HeueSxNYZIs5QMl8ItQQw1vJgszMmfpsfn6tVFx4saakzrUzYVyoWAThDD1gOU9dlK HyiQXAPF/FN957x0TRtnkNcospRxRExlDbDZ4eD2QptGs1zWPU83ea8YSKGrT1Fs+Wjp hR3MPX933DNDxG0YuHXhhntNHqFrb8fkOc6sFyVFAb66p+sQF3mi3TZCrJ8BY4lzcY+u x4TE7PaakswhMM+hjFF7qHmxa3OBM7uVaMMu/3+3M/qxPpxT4fygQ+av69iQGRC0NNL4 5Q73EsfL3c8GjIjPLYFvKYXc1nPHjSMvF+4qk+IsALuSemI4+UC/GX2MNCA6cfldkDiK qGqQ== X-Forwarded-Encrypted: i=1; AJvYcCVjgapKx0QSC7ctv4fYqNeRG7L4qJxl7nrbVRyc5zvk6K6nPYaJpyp75ZPP2c3LMze8lXD5EICv6KZ/yGv4Ul8=@freebsd.org X-Gm-Message-State: AOJu0YyTxhy8yFQm1fudUZJqq8XEWyQ/ZSToQqZPYmxlGVfI2Mfxo4PS cO23SwQ/f7Nd3g/TaqsCQqNKzORvZe3dGE0dqqGlapvXdyvzxPswPDIDyw== X-Gm-Gg: ASbGnctjyqNs0am5RSF5ErhBWVZp1ZSXQB5kTu4pvLSKiX3Y2jBehNWOk4EXUrQrVeZ fe6uhoRYyLDC08o4sbv9KrJLeU7v0no4RzmQWd3vhBy+zg5/p6ziZeEAR+/QDnTL2O7zlSXcMko nIQUQnwENkxWFgYPuYCzZI8EHj/GQcLGbKIRM3JjCTn4rtbTHlDfRY8szUhkFB3WcKZpAI2LsP5 oSnxzVcX8zRMt2MqecUCVS0PLsgOkvFI9yv/inSm+voKHw48zwf7V/kRi6xlvlOodg2w+8= X-Google-Smtp-Source: AGHT+IEekI59MK19PbdMy2hEfVarjE80j1HdIHLoOCNQqFE+YJOBK+BfRZInIkg5MA9f0toenAGfVg== X-Received: by 2002:a05:620a:2947:b0:7b6:e888:6b0e with SMTP id af79cd13be357-7bcd96fa294mr2050606585a.2.1736613250150; Sat, 11 Jan 2025 08:34:10 -0800 (PST) Received: from nuc (192-0-220-237.cpe.teksavvy.com. [192.0.220.237]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-6dfade73235sm21115436d6.90.2025.01.11.08.34.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 11 Jan 2025 08:34:09 -0800 (PST) Date: Sat, 11 Jan 2025 11:34:06 -0500 From: Mark Johnston To: Tomoaki AOKI Cc: Konstantin Belousov , freebsd-hackers@freebsd.org Subject: Re: widening ticks Message-ID: References: <20250111131106.4d2657de20eeed7eef5c0b15@dec.sakura.ne.jp> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250111131106.4d2657de20eeed7eef5c0b15@dec.sakura.ne.jp> X-Rspamd-Queue-Id: 4YVkcg3KP4z4n7L X-Spamd-Bar: ---- 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] On Sat, Jan 11, 2025 at 01:11:06PM +0900, Tomoaki AOKI wrote: > On Wed, 8 Jan 2025 18:07:47 -0500 > Mark Johnston wrote: > > > On Thu, Jan 09, 2025 at 12:18:48AM +0200, Konstantin Belousov wrote: > > > On Wed, Jan 08, 2025 at 04:31:16PM -0500, Mark Johnston wrote: > > > > The global "ticks" variable counts hardclock ticks, it's widely used in > > > > the kernel for low-precision timekeeping. The linuxkpi provides a very > > > > similar variable, "jiffies", but there's an incompatibility: the former > > > > is a signed int and the latter is an unsigned long. It's not > > > > particularly easy to paper over this difference, which has been > > > > responsible for some nasty bugs, and modifying drivers to store the > > > > jiffies value in a signed int is error-prone and a maintenance burden > > > > that the linuxkpi is supposed to avoid. > > > > > > > > It would be nice to provide a compatible implementation of jiffies. I > > > > can see a few approaches: > > > > - Define a 64-bit ticks variable, say ticks64, and make hardclock() > > > > update both ticks and ticks64. Then #define jiffies ticks64 on 64-bit > > > > platforms. This is the simplest to implement, but it adds extra work > > > > to hardclock() and is somewhat ugly. > > > > - Make ticks an int64_t or a long and convert our native code > > > > accordingly. This is cleaner but requires a lot of auditing to avoid > > > > introducing bugs, though perhaps some code could be left unmodified, > > > > implicitly truncating the value to an int. For example I think > > > > sched_pctcpu_update() is fine. I've gotten an amd64 kernel to compile > > > > and boot with this change, but it's hard to be confident in it. This > > > > approach also has the potential downside of bloating structures that > > > > store a ticks value, and it can't be MFCed. > > > > - Introduce a 64-bit ticks variable, ticks64, and > > > > #define ticks ((int)ticks64). This requires renaming any struct > > > > fields and local vars named "ticks", of which there's a decent number, > > > > but that can be done fairly mechanically. > > > > > > > > Is there another solution which avoids these pitfalls? If not, should > > > > we go ahead with one of these approaches? If so, which one? > > > > > > You cannot do this in C, but can in asm: > > > .data > > > .globl ticksl, ticks > > > .type ticksl, @object > > > .type ticks, @object > > > ticksl: .quad > > > .size ticksl, 8 > > > ticks =ticksl /* for little-endian */ > > > /* ticks =ticksl + 4 for big-endian */ > > > .size ticks, 4 > > > > > > > > > Then update only ticksl in the hardclock(). > > > > I implemented your suggestion here: https://reviews.freebsd.org/D48383 > > As this is already committed to main, commenting here instead of review > D48383. > > Maybe I'm too paranoid and overlooking something, but... > > *If "jiffies" in LinuxKPI is really unsigned, isn't there any > possibilities that relies on its value to be larger than > 0x7fffffffffffffff as a threshold? > (Yes, it should be silly and non-realistic, but theoretically > possible.) Ideally we would have #define jiffies ((unsigned long)ticksl) in the linuxkpi, but some Linux code uses "jiffies" as a struct field or local variable name, so this doesn't quite work. In practice, the value is usually assigned to an unsigned long or used as an operand where it would be implicitly promoted to an unsigned type, so we don't see any incompatibilities. When jiffies is an int, code like the following can misbehave: unsigned long remain, timeout = jiffies + const; ... remain = timeout - jiffies; if ((long)remain < 0) /* timed out */ If (int)timeout and jiffies have different signs, as might happen close to a rollover, the comparison won't work as expected. Linux has some macros (time_after() etc.) which are supposed to be used instead of direct comparisons, but they're not always used. > *Is anywhere checking carry (sign) bit for int on LP32? > Maybe it would be the reason if "jiffies" in LinuxKPI is really > unsigned. Could you provide an example of what you mean? From nobody Sat Jan 11 19:35:43 2025 X-Original-To: freebsd-hackers@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 4YVpfG2hHVz4rfHq for ; Sat, 11 Jan 2025 19:35:50 +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 4YVpfF5JVDz45XX; Sat, 11 Jan 2025 19:35:48 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; none Received: from kalamity.joker.local (124-18-43-234.area1a.commufa.jp [124.18.43.234]) (authenticated bits=0) by www121.sakura.ne.jp (8.17.1/8.17.1/[SAKURA-WEB]/20201212) with ESMTPA id 50BJZhI9089182; Sun, 12 Jan 2025 04:35:44 +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=1736624145; bh=rwItZ9lIj7PpidowJxjVow4+1tzVjoCUPVwtZ3Jz014=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=PrR0sjeDNWLgo0RsrXSYl0qApUmzR31h1OQCTfKQFP24hDXnQ2ssSkO0mwGoGzK4e FrHX4B02MLxeXo+D+iC2L7z1jzyftEgV/Qsh+DoScRO2RIEZ3Wn/id2TiD+adDRf5E NReIQM4YN+318y5QTvB5cCs56wTJuU+D1YYZSsIc= Date: Sun, 12 Jan 2025 04:35:43 +0900 From: Tomoaki AOKI To: Mark Johnston Cc: Konstantin Belousov , freebsd-hackers@freebsd.org Subject: Re: widening ticks Message-Id: <20250112043543.86b303419f954b2b287d39d1@dec.sakura.ne.jp> In-Reply-To: References: <20250111131106.4d2657de20eeed7eef5c0b15@dec.sakura.ne.jp> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.2) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4YVpfF5JVDz45XX X-Spamd-Bar: ---- 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] On Sat, 11 Jan 2025 11:34:06 -0500 Mark Johnston wrote: > On Sat, Jan 11, 2025 at 01:11:06PM +0900, Tomoaki AOKI wrote: > > On Wed, 8 Jan 2025 18:07:47 -0500 > > Mark Johnston wrote: > > > > > On Thu, Jan 09, 2025 at 12:18:48AM +0200, Konstantin Belousov wrote: > > > > On Wed, Jan 08, 2025 at 04:31:16PM -0500, Mark Johnston wrote: > > > > > The global "ticks" variable counts hardclock ticks, it's widely used in > > > > > the kernel for low-precision timekeeping. The linuxkpi provides a very > > > > > similar variable, "jiffies", but there's an incompatibility: the former > > > > > is a signed int and the latter is an unsigned long. It's not > > > > > particularly easy to paper over this difference, which has been > > > > > responsible for some nasty bugs, and modifying drivers to store the > > > > > jiffies value in a signed int is error-prone and a maintenance burden > > > > > that the linuxkpi is supposed to avoid. > > > > > > > > > > It would be nice to provide a compatible implementation of jiffies. I > > > > > can see a few approaches: > > > > > - Define a 64-bit ticks variable, say ticks64, and make hardclock() > > > > > update both ticks and ticks64. Then #define jiffies ticks64 on 64-bit > > > > > platforms. This is the simplest to implement, but it adds extra work > > > > > to hardclock() and is somewhat ugly. > > > > > - Make ticks an int64_t or a long and convert our native code > > > > > accordingly. This is cleaner but requires a lot of auditing to avoid > > > > > introducing bugs, though perhaps some code could be left unmodified, > > > > > implicitly truncating the value to an int. For example I think > > > > > sched_pctcpu_update() is fine. I've gotten an amd64 kernel to compile > > > > > and boot with this change, but it's hard to be confident in it. This > > > > > approach also has the potential downside of bloating structures that > > > > > store a ticks value, and it can't be MFCed. > > > > > - Introduce a 64-bit ticks variable, ticks64, and > > > > > #define ticks ((int)ticks64). This requires renaming any struct > > > > > fields and local vars named "ticks", of which there's a decent number, > > > > > but that can be done fairly mechanically. > > > > > > > > > > Is there another solution which avoids these pitfalls? If not, should > > > > > we go ahead with one of these approaches? If so, which one? > > > > > > > > You cannot do this in C, but can in asm: > > > > .data > > > > .globl ticksl, ticks > > > > .type ticksl, @object > > > > .type ticks, @object > > > > ticksl: .quad > > > > .size ticksl, 8 > > > > ticks =ticksl /* for little-endian */ > > > > /* ticks =ticksl + 4 for big-endian */ > > > > .size ticks, 4 > > > > > > > > > > > > Then update only ticksl in the hardclock(). > > > > > > I implemented your suggestion here: https://reviews.freebsd.org/D48383 > > > > As this is already committed to main, commenting here instead of review > > D48383. > > > > Maybe I'm too paranoid and overlooking something, but... > > > > *If "jiffies" in LinuxKPI is really unsigned, isn't there any > > possibilities that relies on its value to be larger than > > 0x7fffffffffffffff as a threshold? > > (Yes, it should be silly and non-realistic, but theoretically > > possible.) > > Ideally we would have > > #define jiffies ((unsigned long)ticksl) > > in the linuxkpi, but some Linux code uses "jiffies" as a struct field or > local variable name, so this doesn't quite work. > > In practice, the value is usually assigned to an unsigned long or used > as an operand where it would be implicitly promoted to an unsigned type, > so we don't see any incompatibilities. > > When jiffies is an int, code like the following can misbehave: > > unsigned long remain, timeout = jiffies + const; > ... > remain = timeout - jiffies; > if ((long)remain < 0) > /* timed out */ > > If (int)timeout and jiffies have different signs, as might happen close > to a rollover, the comparison won't work as expected. > > Linux has some macros (time_after() etc.) which are supposed to be used > instead of direct comparisons, but they're not always used. So ticksl should better be unsigned long if there's no reason to keep it signed, isn't it? > > *Is anywhere checking carry (sign) bit for int on LP32? > > Maybe it would be the reason if "jiffies" in LinuxKPI is really > > unsigned. > > Could you provide an example of what you mean? Not an example of code, but for example, when ticksl is at 0x7fffffffffffffff (positive value), ticks shoule be 0xffffffff (negative value), if I read the diff correctly. The same thing starts happening ticksl is at 0x0000000080000000 throug 0x00000000ffffffff and values alike. So signs (carry bits, usually the leftmost bit of each) should be checked separately for ticksl and ticks. Am I (hopefully) overlooking something? -- Tomoaki AOKI From nobody Sat Jan 11 20:12:24 2025 X-Original-To: freebsd-hackers@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 4YVqSj4PxRz4rjQS for ; Sat, 11 Jan 2025 20:12:37 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pj1-x1030.google.com (mail-pj1-x1030.google.com [IPv6:2607:f8b0:4864:20::1030]) (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 4YVqSj2RC8z4Dxs for ; Sat, 11 Jan 2025 20:12:37 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pj1-x1030.google.com with SMTP id 98e67ed59e1d1-2efe25558ddso3990226a91.2 for ; Sat, 11 Jan 2025 12:12:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1736626355; x=1737231155; 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=L3zOoLd+tOJIW7qfW8jg0LgzWcMRnRhV5JGo/OJljP8=; b=OW1oFkdh+aVEWHJ1IaxyTeZNx6uEtiDJC8IP8ufjXuHOf3fnsj5oQizLoJzBD6naF+ 7LGLQ/iJB8/Hxm5qh18fugExbRd7NReYwjYFxEkk7Zd5160TsFsHvZHUOE3xsD/3BsDV z2edAm85RyWcEvFH8VviY8C2BPyHZ7P4Z0jY9hbfYu3Jicw59oOdOLE6O/CWr86HF7lc ssE4WNuIjgG68aqNhtN2vhghcdgQ4K3TMAshGgDfw0bvTH/ARh1oLHWrmSpBnr1eoA3T KJAB7rJL+nxrQnAcKkWAflJaCH7T25rlJ2CnZKnqLwEwhfr11WdEWZuFKHadkbGHOBur Lsvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736626355; x=1737231155; 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=L3zOoLd+tOJIW7qfW8jg0LgzWcMRnRhV5JGo/OJljP8=; b=n58fcIyUobQx8wefAxLnGN5i8JiDPnhJSmSKKGeuFXDLTBWgPMpvru7Xw4sC8Viggf HHwP2ZB9Da5ENwYV5kki838zGWePsPF/BKwj+T89yzewj0EeczJDXQgi4OOzAHjrNK1q BgaIq8uYulxnmrfQ4HAE3OgMSvtc/023GkCAytiGzOO0WNprqrqG2cqwZv/9sgyxIO8d 1VwUbkEe7MprWshc++iOLt8ItTgHD0VkJ61OhO4I+xAruvNFx3KykEc/F68pnsjuJLmK m5rHVAOlufm0OwyThdBwuURPHXBsqm6IufyU8Ns+rYeytcp/7E3znUQmmjMVbfduuI09 ajTA== X-Forwarded-Encrypted: i=1; AJvYcCUwaeHirxc+n2BJIrCviV9x3xjjFEPtSGZ/CB5gBEAMi7yKVcpARUowKWoXaX1VPwqyVMmQ5zUboAmqxqaaScM=@freebsd.org X-Gm-Message-State: AOJu0YwEfof4rOh4WOFwhSXK+Az6UX2zXehdEjtmx4OHn2RQqPtGZ6aV RpMAxowEsK47/Z6gGoGvOJizmBZv2MlfeOPspe7tz+QvEoZCOfMWzwu+egK/iW+c62aLix1dWm4 25EJjpOoqd4TraSHJxZmmrgo8ayZesI1DtK3RlA== X-Gm-Gg: ASbGnct9/mMVL/DaIy8kdbnRg/7nzz22b8A40HSIcBlQjBE31JncicsKRW0KaKXbGjH moxuP3lMADgjrXjmtq9U9iO4GO+1QmvLGbQl0sOZSi0b94kxTz/Ex3sF2sxpDxRh4SoYoyuqh X-Google-Smtp-Source: AGHT+IEHdYq19ar89wdPNvtcwAh2EcgNew1JUW38Px83g/zVuzpvjI4Dz+/RcANXV6NlyNNe633GWCkJvis3sUJRHCE= X-Received: by 2002:a17:90b:4a44:b0:2ea:61de:38f7 with SMTP id 98e67ed59e1d1-2f548f1d420mr22715989a91.29.1736626355451; Sat, 11 Jan 2025 12:12:35 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 References: <20250111131106.4d2657de20eeed7eef5c0b15@dec.sakura.ne.jp> <20250112043543.86b303419f954b2b287d39d1@dec.sakura.ne.jp> In-Reply-To: <20250112043543.86b303419f954b2b287d39d1@dec.sakura.ne.jp> From: Warner Losh Date: Sat, 11 Jan 2025 13:12:24 -0700 X-Gm-Features: AbW1kvZFWVZM85E1vk66P06qN_NSjvdoPi9uTZXqvDCMXYEzZtvkAXJ7jVyFdOg Message-ID: Subject: Re: widening ticks To: Tomoaki AOKI Cc: Mark Johnston , Konstantin Belousov , FreeBSD Hackers Content-Type: multipart/alternative; boundary="0000000000000658a3062b73d52d" X-Rspamd-Queue-Id: 4YVqSj2RC8z4Dxs X-Spamd-Bar: ---- 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] --0000000000000658a3062b73d52d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Why not have jiffiesjust be an alias for tickl at the assembler level, then just have extern unsigned long jiffies; so the types match and we don't have fragile macros? At the assembler level, long and unsigned long are the sane for object definition. Warner On Sat, Jan 11, 2025, 12:36=E2=80=AFPM Tomoaki AOKI wrote: > On Sat, 11 Jan 2025 11:34:06 -0500 > Mark Johnston wrote: > > > On Sat, Jan 11, 2025 at 01:11:06PM +0900, Tomoaki AOKI wrote: > > > On Wed, 8 Jan 2025 18:07:47 -0500 > > > Mark Johnston wrote: > > > > > > > On Thu, Jan 09, 2025 at 12:18:48AM +0200, Konstantin Belousov wrote= : > > > > > On Wed, Jan 08, 2025 at 04:31:16PM -0500, Mark Johnston wrote: > > > > > > The global "ticks" variable counts hardclock ticks, it's widely > used in > > > > > > the kernel for low-precision timekeeping. The linuxkpi provide= s > a very > > > > > > similar variable, "jiffies", but there's an incompatibility: th= e > former > > > > > > is a signed int and the latter is an unsigned long. It's not > > > > > > particularly easy to paper over this difference, which has been > > > > > > responsible for some nasty bugs, and modifying drivers to store > the > > > > > > jiffies value in a signed int is error-prone and a maintenance > burden > > > > > > that the linuxkpi is supposed to avoid. > > > > > > > > > > > > It would be nice to provide a compatible implementation of > jiffies. I > > > > > > can see a few approaches: > > > > > > - Define a 64-bit ticks variable, say ticks64, and make > hardclock() > > > > > > update both ticks and ticks64. Then #define jiffies ticks64 > on 64-bit > > > > > > platforms. This is the simplest to implement, but it adds > extra work > > > > > > to hardclock() and is somewhat ugly. > > > > > > - Make ticks an int64_t or a long and convert our native code > > > > > > accordingly. This is cleaner but requires a lot of auditing > to avoid > > > > > > introducing bugs, though perhaps some code could be left > unmodified, > > > > > > implicitly truncating the value to an int. For example I thi= nk > > > > > > sched_pctcpu_update() is fine. I've gotten an amd64 kernel t= o > compile > > > > > > and boot with this change, but it's hard to be confident in > it. This > > > > > > approach also has the potential downside of bloating > structures that > > > > > > store a ticks value, and it can't be MFCed. > > > > > > - Introduce a 64-bit ticks variable, ticks64, and > > > > > > #define ticks ((int)ticks64). This requires renaming any > struct > > > > > > fields and local vars named "ticks", of which there's a decen= t > number, > > > > > > but that can be done fairly mechanically. > > > > > > > > > > > > Is there another solution which avoids these pitfalls? If not, > should > > > > > > we go ahead with one of these approaches? If so, which one? > > > > > > > > > > You cannot do this in C, but can in asm: > > > > > .data > > > > > .globl ticksl, ticks > > > > > .type ticksl, @object > > > > > .type ticks, @object > > > > > ticksl: .quad > > > > > .size ticksl, 8 > > > > > ticks =3Dticksl /* for little-endian */ > > > > > /* ticks =3Dticksl + 4 for big-endian */ > > > > > .size ticks, 4 > > > > > > > > > > > > > > > Then update only ticksl in the hardclock(). > > > > > > > > I implemented your suggestion here: > https://reviews.freebsd.org/D48383 > > > > > > As this is already committed to main, commenting here instead of revi= ew > > > D48383. > > > > > > Maybe I'm too paranoid and overlooking something, but... > > > > > > *If "jiffies" in LinuxKPI is really unsigned, isn't there any > > > possibilities that relies on its value to be larger than > > > 0x7fffffffffffffff as a threshold? > > > (Yes, it should be silly and non-realistic, but theoretically > > > possible.) > > > > Ideally we would have > > > > #define jiffies ((unsigned long)ticksl) > > > > in the linuxkpi, but some Linux code uses "jiffies" as a struct field o= r > > local variable name, so this doesn't quite work. > > > > In practice, the value is usually assigned to an unsigned long or used > > as an operand where it would be implicitly promoted to an unsigned type= , > > so we don't see any incompatibilities. > > > > When jiffies is an int, code like the following can misbehave: > > > > unsigned long remain, timeout =3D jiffies + const; > > ... > > remain =3D timeout - jiffies; > > if ((long)remain < 0) > > /* timed out */ > > > > If (int)timeout and jiffies have different signs, as might happen close > > to a rollover, the comparison won't work as expected. > > > > Linux has some macros (time_after() etc.) which are supposed to be used > > instead of direct comparisons, but they're not always used. > > So ticksl should better be unsigned long if there's no reason to keep > it signed, isn't it? > > > > > *Is anywhere checking carry (sign) bit for int on LP32? > > > Maybe it would be the reason if "jiffies" in LinuxKPI is really > > > unsigned. > > > > Could you provide an example of what you mean? > > Not an example of code, but for example, when ticksl is at > 0x7fffffffffffffff (positive value), ticks shoule be 0xffffffff > (negative value), if I read the diff correctly. > The same thing starts happening ticksl is at 0x0000000080000000 throug > 0x00000000ffffffff and values alike. So signs (carry bits, usually the > leftmost bit of each) should be checked separately for ticksl and ticks. > > Am I (hopefully) overlooking something? > > -- > Tomoaki AOKI > > --0000000000000658a3062b73d52d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Why not have jiffiesjust be an alias for tickl at the ass= embler level, then just have extern unsigned long jiffies; so the types mat= ch and we don't have fragile macros? At the assembler level, long and u= nsigned long are the sane for object definition.=C2=A0
Warner

On Sat, Jan 11, = 2025, 12:36=E2=80=AFPM Tomoaki AOKI <junchoon@dec.sakura.ne.jp> wrote:
On Sat, 11 Jan 2025 11:34:06 -0500
Mark Johnston <markj@freebsd.org> wrote:

> On Sat, Jan 11, 2025 at 01:11:06PM +0900, Tomoaki AOKI wrote:
> > On Wed, 8 Jan 2025 18:07:47 -0500
> > Mark Johnston <markj@freebsd.org> wrote:
> >
> > > On Thu, Jan 09, 2025 at 12:18:48AM +0200, Konstantin Belouso= v wrote:
> > > > On Wed, Jan 08, 2025 at 04:31:16PM -0500, Mark Johnston= wrote:
> > > > > The global "ticks" variable counts hardc= lock ticks, it's widely used in
> > > > > the kernel for low-precision timekeeping.=C2=A0 Th= e linuxkpi provides a very
> > > > > similar variable, "jiffies", but there&#= 39;s an incompatibility: the former
> > > > > is a signed int and the latter is an unsigned long= .=C2=A0 It's not
> > > > > particularly easy to paper over this difference, w= hich has been
> > > > > responsible for some nasty bugs, and modifying dri= vers to store the
> > > > > jiffies value in a signed int is error-prone and a= maintenance burden
> > > > > that the linuxkpi is supposed to avoid.
> > > > >
> > > > > It would be nice to provide a compatible implement= ation of jiffies.=C2=A0 I
> > > > > can see a few approaches:
> > > > > - Define a 64-bit ticks variable, say ticks64, and= make hardclock()
> > > > >=C2=A0 =C2=A0update both ticks and ticks64.=C2=A0 T= hen #define jiffies ticks64 on 64-bit
> > > > >=C2=A0 =C2=A0platforms.=C2=A0 This is the simplest = to implement, but it adds extra work
> > > > >=C2=A0 =C2=A0to hardclock() and is somewhat ugly. > > > > > - Make ticks an int64_t or a long and convert our = native code
> > > > >=C2=A0 =C2=A0accordingly.=C2=A0 This is cleaner but= requires a lot of auditing to avoid
> > > > >=C2=A0 =C2=A0introducing bugs, though perhaps some = code could be left unmodified,
> > > > >=C2=A0 =C2=A0implicitly truncating the value to an = int.=C2=A0 For example I think
> > > > >=C2=A0 =C2=A0sched_pctcpu_update() is fine.=C2=A0 I= 've gotten an amd64 kernel to compile
> > > > >=C2=A0 =C2=A0and boot with this change, but it'= s hard to be confident in it.=C2=A0 This
> > > > >=C2=A0 =C2=A0approach also has the potential downsi= de of bloating structures that
> > > > >=C2=A0 =C2=A0store a ticks value, and it can't = be MFCed.
> > > > > - Introduce a 64-bit ticks variable, ticks64, and<= br> > > > > >=C2=A0 =C2=A0#define ticks ((int)ticks64).=C2=A0 Th= is requires renaming any struct
> > > > >=C2=A0 =C2=A0fields and local vars named "tick= s", of which there's a decent number,
> > > > >=C2=A0 =C2=A0but that can be done fairly mechanical= ly.
> > > > >
> > > > > Is there another solution which avoids these pitfa= lls?=C2=A0 If not, should
> > > > > we go ahead with one of these approaches?=C2=A0 If= so, which one?
> > > >
> > > > You cannot do this in C, but can in asm:
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0.data
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0.globl=C2=A0 ticksl, t= icks
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0.type=C2=A0 =C2=A0tick= sl, @object
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0.type=C2=A0 =C2=A0tick= s, @object
> > > > ticksl: .quad
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0.size=C2=A0 =C2=A0tick= sl, 8
> > > > ticks=C2=A0 =C2=A0=3Dticksl=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0/* for little-endian */
> > > > /* ticks=C2=A0 =C2=A0 =C2=A0 =C2=A0 =3Dticksl + 4=C2=A0= for big-endian */
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0.size=C2=A0 =C2=A0tick= s, 4
> > > >
> > > >
> > > > Then update only ticksl in the hardclock().
> > >
> > > I implemented your suggestion here: http= s://reviews.freebsd.org/D48383
> >
> > As this is already committed to main, commenting here instead of = review
> > D48383.
> >
> > Maybe I'm too paranoid and overlooking something, but...
> >
> > *If "jiffies" in LinuxKPI is really unsigned, isn't= there any
> >=C2=A0 possibilities that relies on its value to be larger than > >=C2=A0 0x7fffffffffffffff as a threshold?
> >=C2=A0 (Yes, it should be silly and non-realistic, but theoretical= ly
> >=C2=A0 =C2=A0possible.)
>
> Ideally we would have
>
>=C2=A0 =C2=A0 =C2=A0#define jiffies ((unsigned long)ticksl)
>
> in the linuxkpi, but some Linux code uses "jiffies" as a str= uct field or
> local variable name, so this doesn't quite work.
>
> In practice, the value is usually assigned to an unsigned long or used=
> as an operand where it would be implicitly promoted to an unsigned typ= e,
> so we don't see any incompatibilities.
>
> When jiffies is an int, code like the following can misbehave:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0unsigned long remain, timeout =3D jiffies + = const;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0...
>=C2=A0 =C2=A0 =C2=A0 =C2=A0remain =3D timeout - jiffies;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0if ((long)remain < 0)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/* timed out */<= br> >
> If (int)timeout and jiffies have different signs, as might happen clos= e
> to a rollover, the comparison won't work as expected.
>
> Linux has some macros (time_after() etc.) which are supposed to be use= d
> instead of direct comparisons, but they're not always used.

So ticksl should better be unsigned long if there's no reason to keep it signed, isn't it?


> > *Is anywhere checking carry (sign) bit for int on LP32?
> >=C2=A0 Maybe it would be the reason if "jiffies" in Linu= xKPI is really
> >=C2=A0 unsigned.
>
> Could you provide an example of what you mean?

Not an example of code, but for example, when ticksl is at
0x7fffffffffffffff (positive value), ticks shoule be 0xffffffff
(negative value), if I read the diff correctly.
The same thing starts happening ticksl is at 0x0000000080000000 throug
0x00000000ffffffff and values alike. So signs (carry bits, usually the
leftmost bit of each) should be checked separately for ticksl and ticks.
Am I (hopefully) overlooking something?

--
Tomoaki AOKI=C2=A0 =C2=A0 <junchoon@dec.sakura.ne.jp>

--0000000000000658a3062b73d52d-- From nobody Sat Jan 11 22:35:36 2025 X-Original-To: freebsd-hackers@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 4YVtdm52R6z5jvwQ for ; Sat, 11 Jan 2025 22:35:40 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (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 4YVtdm2mnWz4SKs for ; Sat, 11 Jan 2025 22:35:40 +0000 (UTC) (envelope-from markjdb@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-qk1-x733.google.com with SMTP id af79cd13be357-7b6ea711805so406691985a.1 for ; Sat, 11 Jan 2025 14:35:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736634939; x=1737239739; darn=freebsd.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:from:to:cc:subject:date:message-id :reply-to; bh=DuhN1+n0bEvdZs6w2zz67/7rBmd3eTi7XetjHIUon0w=; b=R+YU98ERA49oBxEPachMbjO8Th4oPgbQncl/UQt9iCxtYkuNKVgcGzpY674J323Wc0 9aJD3DLGWWdcSH7k7wI6SaGBMEOv8VglSCWd+Ku2e4RFJErZ2W3vv7nMR758xbJhTBHk 8Y2H5Jj8NLuaC0sVJYHyTia8CgGf2rC++NeXVh10b29JGWQBNCGfcemmoX5p4pfOUNx5 cRhypOJTFxMg7LaN/6olZ/yqmYebW/jU+uSpolm+VV2Iz4pn9OKhYoLj+xI230nZ2H3H tNTY7Gu7g9UmP19chOPbsOW5zemUayLk3s71vO+hCh6+uj1vAJvQu05ds7q0RKWgVUOd d2OQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736634939; x=1737239739; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=DuhN1+n0bEvdZs6w2zz67/7rBmd3eTi7XetjHIUon0w=; b=mnCylZnQ5LI/OAAkJu2weq0AFEB0X29moU+DAegUnpW+fYcYE69KNrvG1ZnBF8dqQv NSC4utHrDW75Evs9RRQxxKqjyH/mMKy3dHDfAL2m7hlp8940NCcfhtqTpmDL/Wn/bcEo 145nATjXtC7pxm09cR+5GzMxJjj0tV5OnhWCyTubHZ3QEg5iUrHHZecMWvmL2A68oQqm oBDCalc41GIzTjxEcHjD/zHXOEKCa9velDhI56GudBxW5SnY4QodDLUQwQJsdDQZvLnw 6v9k5g2Im6nZsEQEBNMECE2deAoKpVJC5IZ7G3Hqe7//BZLxYNRcEAJEoTp80V9pKTaw KPHA== X-Forwarded-Encrypted: i=1; AJvYcCUNbdUmSSI1tJC+KurVusT6B4qqOMJS/DRwo8q9eoOnCQoflPds7XTXVOmW5f4tGlvtprbR6sTBAlE+aBEaqD4=@freebsd.org X-Gm-Message-State: AOJu0Yym3wk0UIiXd5wWKR4pFymanX1YvQX3Nvzx2y8vHjdJSKoETNwX e3UFsrpnLhBp6qSTKau5Vre120s+qGKFkEHc8ChxH+I3m46imeN92x2UoA== X-Gm-Gg: ASbGncsIT/Cdlz9WQEE0cw882wCbutZ6X/im1lDMvEEmlctnSY+96ueGZQkgyJf6tkO YaMnfDU8T0PPXdR9thl3wSNzDXe15qvZjXZH4040dCWLFo9hrrDs5hK7LaqGWCG+YTyu7h+IVEu EhhII0fEY6M0nKBF56dI5g4o+TLpVyz7bNGn1cZijWrWTInFusV8UlowVWWdHNtSA3hFZfdy5PT EXJGT92WfQjvnIKQ4i/1MO/+GftZ14mLRGpd7Il+Sxmi3rs2ux94ywJTEPxZY+/JhzMcyI= X-Google-Smtp-Source: AGHT+IG95Tqas1k5YDfriekZNn4d4uiIPiq1raff+o0QzdG0rUNkBMTC/DIG8CX8tw4hxkoBgs5Ngw== X-Received: by 2002:a05:620a:2951:b0:7b6:67df:51e3 with SMTP id af79cd13be357-7bcd973892amr2365429785a.16.1736634939396; Sat, 11 Jan 2025 14:35:39 -0800 (PST) Received: from nuc (192-0-220-237.cpe.teksavvy.com. [192.0.220.237]) by smtp.gmail.com with ESMTPSA id af79cd13be357-7bce324828esm323535085a.45.2025.01.11.14.35.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 11 Jan 2025 14:35:39 -0800 (PST) Date: Sat, 11 Jan 2025 17:35:36 -0500 From: Mark Johnston To: Tomoaki AOKI Cc: Konstantin Belousov , freebsd-hackers@freebsd.org Subject: Re: widening ticks Message-ID: References: <20250111131106.4d2657de20eeed7eef5c0b15@dec.sakura.ne.jp> <20250112043543.86b303419f954b2b287d39d1@dec.sakura.ne.jp> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250112043543.86b303419f954b2b287d39d1@dec.sakura.ne.jp> X-Rspamd-Queue-Id: 4YVtdm2mnWz4SKs X-Spamd-Bar: ---- 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] On Sun, Jan 12, 2025 at 04:35:43AM +0900, Tomoaki AOKI wrote: > On Sat, 11 Jan 2025 11:34:06 -0500 > Mark Johnston wrote: > > > On Sat, Jan 11, 2025 at 01:11:06PM +0900, Tomoaki AOKI wrote: > > > On Wed, 8 Jan 2025 18:07:47 -0500 > > > Mark Johnston wrote: > > > > > > > On Thu, Jan 09, 2025 at 12:18:48AM +0200, Konstantin Belousov wrote: > > > > > On Wed, Jan 08, 2025 at 04:31:16PM -0500, Mark Johnston wrote: > > > > > > The global "ticks" variable counts hardclock ticks, it's widely used in > > > > > > the kernel for low-precision timekeeping. The linuxkpi provides a very > > > > > > similar variable, "jiffies", but there's an incompatibility: the former > > > > > > is a signed int and the latter is an unsigned long. It's not > > > > > > particularly easy to paper over this difference, which has been > > > > > > responsible for some nasty bugs, and modifying drivers to store the > > > > > > jiffies value in a signed int is error-prone and a maintenance burden > > > > > > that the linuxkpi is supposed to avoid. > > > > > > > > > > > > It would be nice to provide a compatible implementation of jiffies. I > > > > > > can see a few approaches: > > > > > > - Define a 64-bit ticks variable, say ticks64, and make hardclock() > > > > > > update both ticks and ticks64. Then #define jiffies ticks64 on 64-bit > > > > > > platforms. This is the simplest to implement, but it adds extra work > > > > > > to hardclock() and is somewhat ugly. > > > > > > - Make ticks an int64_t or a long and convert our native code > > > > > > accordingly. This is cleaner but requires a lot of auditing to avoid > > > > > > introducing bugs, though perhaps some code could be left unmodified, > > > > > > implicitly truncating the value to an int. For example I think > > > > > > sched_pctcpu_update() is fine. I've gotten an amd64 kernel to compile > > > > > > and boot with this change, but it's hard to be confident in it. This > > > > > > approach also has the potential downside of bloating structures that > > > > > > store a ticks value, and it can't be MFCed. > > > > > > - Introduce a 64-bit ticks variable, ticks64, and > > > > > > #define ticks ((int)ticks64). This requires renaming any struct > > > > > > fields and local vars named "ticks", of which there's a decent number, > > > > > > but that can be done fairly mechanically. > > > > > > > > > > > > Is there another solution which avoids these pitfalls? If not, should > > > > > > we go ahead with one of these approaches? If so, which one? > > > > > > > > > > You cannot do this in C, but can in asm: > > > > > .data > > > > > .globl ticksl, ticks > > > > > .type ticksl, @object > > > > > .type ticks, @object > > > > > ticksl: .quad > > > > > .size ticksl, 8 > > > > > ticks =ticksl /* for little-endian */ > > > > > /* ticks =ticksl + 4 for big-endian */ > > > > > .size ticks, 4 > > > > > > > > > > > > > > > Then update only ticksl in the hardclock(). > > > > > > > > I implemented your suggestion here: https://reviews.freebsd.org/D48383 > > > > > > As this is already committed to main, commenting here instead of review > > > D48383. > > > > > > Maybe I'm too paranoid and overlooking something, but... > > > > > > *If "jiffies" in LinuxKPI is really unsigned, isn't there any > > > possibilities that relies on its value to be larger than > > > 0x7fffffffffffffff as a threshold? > > > (Yes, it should be silly and non-realistic, but theoretically > > > possible.) > > > > Ideally we would have > > > > #define jiffies ((unsigned long)ticksl) > > > > in the linuxkpi, but some Linux code uses "jiffies" as a struct field or > > local variable name, so this doesn't quite work. > > > > In practice, the value is usually assigned to an unsigned long or used > > as an operand where it would be implicitly promoted to an unsigned type, > > so we don't see any incompatibilities. > > > > When jiffies is an int, code like the following can misbehave: > > > > unsigned long remain, timeout = jiffies + const; > > ... > > remain = timeout - jiffies; > > if ((long)remain < 0) > > /* timed out */ > > > > If (int)timeout and jiffies have different signs, as might happen close > > to a rollover, the comparison won't work as expected. > > > > Linux has some macros (time_after() etc.) which are supposed to be used > > instead of direct comparisons, but they're not always used. > > So ticksl should better be unsigned long if there's no reason to keep > it signed, isn't it? Well, I kept it signed since it's meant to be similar in usage to ticks. With a signed counter, you can check test whether a value has passed by looking at the sign of the difference between ticks(l) and that value (modulo rollover). With an unsigned counter, you need some casting, as in the example above. > > > *Is anywhere checking carry (sign) bit for int on LP32? > > > Maybe it would be the reason if "jiffies" in LinuxKPI is really > > > unsigned. > > > > Could you provide an example of what you mean? > > Not an example of code, but for example, when ticksl is at > 0x7fffffffffffffff (positive value), ticks shoule be 0xffffffff > (negative value), if I read the diff correctly. > The same thing starts happening ticksl is at 0x0000000080000000 throug > 0x00000000ffffffff and values alike. So signs (carry bits, usually the > leftmost bit of each) should be checked separately for ticksl and ticks. That's true, but I can't see why any code would care about this? > Am I (hopefully) overlooking something? > > -- > Tomoaki AOKI From nobody Sat Jan 11 22:40:39 2025 X-Original-To: freebsd-hackers@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 4YVtlc2LMGz5jwG9 for ; Sat, 11 Jan 2025 22:40:44 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (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 4YVtlb4c8Xz4SvR for ; Sat, 11 Jan 2025 22:40:43 +0000 (UTC) (envelope-from markjdb@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-qk1-x72d.google.com with SMTP id af79cd13be357-7b6f8524f23so350901685a.2 for ; Sat, 11 Jan 2025 14:40:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736635243; x=1737240043; darn=freebsd.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:from:to:cc:subject:date:message-id :reply-to; bh=St+FBU/yzHqqyDkdhyg7Id4mCF5lvLi3kHOWFnc/VlY=; b=Bq0s1WWbHPBGd6rPmBgCHWs0OTJOe3lO+r+KcnUHF10vtuWoCcEXOA4av2quWYUUW8 qjE4XmsVmPSKYmHDY5XmTfVr9+tY0Bb+9irfQikU5N+LXDeR82yMzs6LNPREr3o1g+hZ cZeiuRhhwO2TwPJSG7rvYr56kcE+ysQM6L2etg1wR01S6WZFmJkTo0QAwW1abK3Wr8yV Z63T/ty+D4E4Rc8gq9DhebEI1dVWjX7f6qcWlgEsmOwBbR9ENQPX0kY5HSwcEVHW4ojm Jeumt1DUiIC9HtSot5qIkbJ/XzpuWvcHuqx9+Hg15f9k+/FAucypTMMA+JUMyz+8atH8 Z5Zw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736635243; x=1737240043; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=St+FBU/yzHqqyDkdhyg7Id4mCF5lvLi3kHOWFnc/VlY=; b=Vk3wxZ1bE2PYW0YlzmouI9qHVeSuif87F3AfJIpOTSmphSD0Keze8lGY49EsLYe8pa /q8O+ynZFPjcccZqfgmGUMHVlFpbcK9w6/wrR7PH8DbFMcE9Dkb3qJxQTsiQEO2bXNS2 1ceRoyKM5Coij8ucCpFckfIvjm4OAaMlHmzyCkxhfF3tvLuLF+KOSn7aHxM6DT2TU6aG v29wOuaWzYgvZ6VGX/Wi7g5Ihfb+KMemxgSElceieqOGFaQxP01APlsgc1vOLWUvAKNZ a7Jwzwl/cVy9J/Cnr9WsBcb27YapTMm6hmlvVgfp1jzW5pt0K70uozs3wsT9JWgML4v0 VUIw== X-Forwarded-Encrypted: i=1; AJvYcCUe1zpQZ2BSl5E5EWPHxnKJ6kloum1h36pZKhNja29/WFmd2W2Bix55Id5hU1D7Jglt40f0qM+HkmvxYIv+iIc=@freebsd.org X-Gm-Message-State: AOJu0YyBFVnVciERrdkX7aTPsVi+us6z0UEYCJc8Ewxb5WpACnyhosi7 6XU8mOzPbm7/meaToIs3Ca4yIQLdevtS9tCmIucEubWzdrbpOOIc X-Gm-Gg: ASbGncuWVt3Cu2E7wl90Zu/Ek0Wh7NbZIr+5WMXpDHq8R7XeDYt69zanlnQb4VtUWtJ 0u4SJIJoDMUPbg9uyeGcTtgeTjli5HRB+qOP5Cpgio2B6OFUzbJXripIOz27twsTekrVFl1W+8O bbED3ZBWSIiiyloWXP87x69AIAw1T0cZ/Cpn3p9pE/pxwUZCh01P20v5HoszYf11YUwMgcKUcco 0t51Hd9cXci4Mtsj50tIb3xP9vPSowzNeFtZv0A6U3lRlN+U9HB+koW8nwcbija80UWl3c= X-Google-Smtp-Source: AGHT+IF/bmYy6zZKhQ/XdBSM7HEWcKldjF+Dxr4HXMPJcLDSUwX/pOwDOqB3w/Mo6lV122ErjCWkKQ== X-Received: by 2002:a05:620a:40c4:b0:7b6:c92e:2e83 with SMTP id af79cd13be357-7bcd9739fb7mr2262735385a.17.1736635242719; Sat, 11 Jan 2025 14:40:42 -0800 (PST) Received: from nuc (192-0-220-237.cpe.teksavvy.com. [192.0.220.237]) by smtp.gmail.com with ESMTPSA id af79cd13be357-7bce3237e3bsm324353485a.23.2025.01.11.14.40.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 11 Jan 2025 14:40:42 -0800 (PST) Date: Sat, 11 Jan 2025 17:40:39 -0500 From: Mark Johnston To: Warner Losh Cc: Tomoaki AOKI , Konstantin Belousov , FreeBSD Hackers Subject: Re: widening ticks Message-ID: References: <20250111131106.4d2657de20eeed7eef5c0b15@dec.sakura.ne.jp> <20250112043543.86b303419f954b2b287d39d1@dec.sakura.ne.jp> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4YVtlb4c8Xz4SvR X-Spamd-Bar: ---- 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] On Sat, Jan 11, 2025 at 01:12:24PM -0700, Warner Losh wrote: > Why not have jiffiesjust be an alias for tickl at the assembler level, then > just have extern unsigned long jiffies; so the types match and we don't > have fragile macros? At the assembler level, long and unsigned long are the > sane for object definition. We certainly could. I guess Linux code which does something like print("%lu\n", jiffies); will be incomatible otherwise. Aside from that, I'm not sure if any code would be affected by the difference in practice, but it's easy to add an alias. From nobody Sat Jan 11 22:42:18 2025 X-Original-To: freebsd-hackers@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 4YVtnc5j2Pz5jwPG for ; Sat, 11 Jan 2025 22:42:28 +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 4YVtnc1TVjz4VTv; Sat, 11 Jan 2025 22:42:27 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; none Received: from kalamity.joker.local (124-18-43-234.area1a.commufa.jp [124.18.43.234]) (authenticated bits=0) by www121.sakura.ne.jp (8.17.1/8.17.1/[SAKURA-WEB]/20201212) with ESMTPA id 50BMgI2i030817; Sun, 12 Jan 2025 07:42:20 +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=1736635340; bh=8Gi5bMjcYT44EsdsiCKWmkmMNZaNipYEvQZazUDvASc=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=agMM/fiVYyfMuYv9IIS7MMidoOQTNLevwspWIzqGob+dZoGg3Q2m9DuOHqQpo3+MV iH0ZKw5UWUx7FFzwZuvP/+zP4FoK8xcxO3f3cvlcSihABOgerYm32shdHqY77dcCao ejVZXc7iOmDq98dklka8K6/w6lnB5PEyqJmNaoTU= Date: Sun, 12 Jan 2025 07:42:18 +0900 From: Tomoaki AOKI To: Warner Losh Cc: Mark Johnston , Konstantin Belousov , FreeBSD Hackers Subject: Re: widening ticks Message-Id: <20250112074218.baa88390293ead0e2836ec08@dec.sakura.ne.jp> In-Reply-To: References: <20250111131106.4d2657de20eeed7eef5c0b15@dec.sakura.ne.jp> <20250112043543.86b303419f954b2b287d39d1@dec.sakura.ne.jp> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.2) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4YVtnc1TVjz4VTv X-Spamd-Bar: ---- 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] On Sat, 11 Jan 2025 13:12:24 -0700 Warner Losh wrote: > Why not have jiffiesjust be an alias for tickl at the assembler level, then > just have extern unsigned long jiffies; so the types match and we don't > have fragile macros? At the assembler level, long and unsigned long are the > sane for object definition. Basically I like this idea, but why I didn't proposed this is that "jiffies" is stated (sorry, not read the LinuxKPI code) to be unsigned long, while tickl is defined as (signed) int in the diff committed. Yes, I know it's just how the bit pattern of the same size is interpreted, but would need some safeguards in C part. > > Warner > > On Sat, Jan 11, 2025, 12:36 PM Tomoaki AOKI > wrote: > > > On Sat, 11 Jan 2025 11:34:06 -0500 > > Mark Johnston wrote: > > > > > On Sat, Jan 11, 2025 at 01:11:06PM +0900, Tomoaki AOKI wrote: > > > > On Wed, 8 Jan 2025 18:07:47 -0500 > > > > Mark Johnston wrote: > > > > > > > > > On Thu, Jan 09, 2025 at 12:18:48AM +0200, Konstantin Belousov wrote: > > > > > > On Wed, Jan 08, 2025 at 04:31:16PM -0500, Mark Johnston wrote: > > > > > > > The global "ticks" variable counts hardclock ticks, it's widely > > used in > > > > > > > the kernel for low-precision timekeeping. The linuxkpi provides > > a very > > > > > > > similar variable, "jiffies", but there's an incompatibility: the > > former > > > > > > > is a signed int and the latter is an unsigned long. It's not > > > > > > > particularly easy to paper over this difference, which has been > > > > > > > responsible for some nasty bugs, and modifying drivers to store > > the > > > > > > > jiffies value in a signed int is error-prone and a maintenance > > burden > > > > > > > that the linuxkpi is supposed to avoid. > > > > > > > > > > > > > > It would be nice to provide a compatible implementation of > > jiffies. I > > > > > > > can see a few approaches: > > > > > > > - Define a 64-bit ticks variable, say ticks64, and make > > hardclock() > > > > > > > update both ticks and ticks64. Then #define jiffies ticks64 > > on 64-bit > > > > > > > platforms. This is the simplest to implement, but it adds > > extra work > > > > > > > to hardclock() and is somewhat ugly. > > > > > > > - Make ticks an int64_t or a long and convert our native code > > > > > > > accordingly. This is cleaner but requires a lot of auditing > > to avoid > > > > > > > introducing bugs, though perhaps some code could be left > > unmodified, > > > > > > > implicitly truncating the value to an int. For example I think > > > > > > > sched_pctcpu_update() is fine. I've gotten an amd64 kernel to > > compile > > > > > > > and boot with this change, but it's hard to be confident in > > it. This > > > > > > > approach also has the potential downside of bloating > > structures that > > > > > > > store a ticks value, and it can't be MFCed. > > > > > > > - Introduce a 64-bit ticks variable, ticks64, and > > > > > > > #define ticks ((int)ticks64). This requires renaming any > > struct > > > > > > > fields and local vars named "ticks", of which there's a decent > > number, > > > > > > > but that can be done fairly mechanically. > > > > > > > > > > > > > > Is there another solution which avoids these pitfalls? If not, > > should > > > > > > > we go ahead with one of these approaches? If so, which one? > > > > > > > > > > > > You cannot do this in C, but can in asm: > > > > > > .data > > > > > > .globl ticksl, ticks > > > > > > .type ticksl, @object > > > > > > .type ticks, @object > > > > > > ticksl: .quad > > > > > > .size ticksl, 8 > > > > > > ticks =ticksl /* for little-endian */ > > > > > > /* ticks =ticksl + 4 for big-endian */ > > > > > > .size ticks, 4 > > > > > > > > > > > > > > > > > > Then update only ticksl in the hardclock(). > > > > > > > > > > I implemented your suggestion here: > > https://reviews.freebsd.org/D48383 > > > > > > > > As this is already committed to main, commenting here instead of review > > > > D48383. > > > > > > > > Maybe I'm too paranoid and overlooking something, but... > > > > > > > > *If "jiffies" in LinuxKPI is really unsigned, isn't there any > > > > possibilities that relies on its value to be larger than > > > > 0x7fffffffffffffff as a threshold? > > > > (Yes, it should be silly and non-realistic, but theoretically > > > > possible.) > > > > > > Ideally we would have > > > > > > #define jiffies ((unsigned long)ticksl) > > > > > > in the linuxkpi, but some Linux code uses "jiffies" as a struct field or > > > local variable name, so this doesn't quite work. > > > > > > In practice, the value is usually assigned to an unsigned long or used > > > as an operand where it would be implicitly promoted to an unsigned type, > > > so we don't see any incompatibilities. > > > > > > When jiffies is an int, code like the following can misbehave: > > > > > > unsigned long remain, timeout = jiffies + const; > > > ... > > > remain = timeout - jiffies; > > > if ((long)remain < 0) > > > /* timed out */ > > > > > > If (int)timeout and jiffies have different signs, as might happen close > > > to a rollover, the comparison won't work as expected. > > > > > > Linux has some macros (time_after() etc.) which are supposed to be used > > > instead of direct comparisons, but they're not always used. > > > > So ticksl should better be unsigned long if there's no reason to keep > > it signed, isn't it? > > > > > > > > *Is anywhere checking carry (sign) bit for int on LP32? > > > > Maybe it would be the reason if "jiffies" in LinuxKPI is really > > > > unsigned. > > > > > > Could you provide an example of what you mean? > > > > Not an example of code, but for example, when ticksl is at > > 0x7fffffffffffffff (positive value), ticks shoule be 0xffffffff > > (negative value), if I read the diff correctly. > > The same thing starts happening ticksl is at 0x0000000080000000 throug > > 0x00000000ffffffff and values alike. So signs (carry bits, usually the > > leftmost bit of each) should be checked separately for ticksl and ticks. > > > > Am I (hopefully) overlooking something? > > > > -- > > Tomoaki AOKI -- Tomoaki AOKI From nobody Sat Jan 11 22:50:38 2025 X-Original-To: freebsd-hackers@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 4YVtz708Xhz5jx8V for ; Sat, 11 Jan 2025 22:50:43 +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 4YVtz620KXz4WRM; Sat, 11 Jan 2025 22:50:42 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; none Received: from kalamity.joker.local (124-18-43-234.area1a.commufa.jp [124.18.43.234]) (authenticated bits=0) by www121.sakura.ne.jp (8.17.1/8.17.1/[SAKURA-WEB]/20201212) with ESMTPA id 50BModQR032640; Sun, 12 Jan 2025 07:50:39 +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=1736635839; bh=nLF4Q9F3Ox4RHmlkK+H4E9F6rwVGgNnB9nVZwk5v5co=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=O/zuhbOLAwQcelbyhk5yxTEkdbz3yq7VHxoNgv2mF5sre5fpK+UC4snCN0JcnSW11 2otsTQ+ol3gcZgTCCvMl2hSH3viaE/lqpZk9sIgDAqBL+z6shWW4oq/x6l2mRIi8Om XigDhWjgvYHrctsBTpcvyHIVdFpJgCw5Lx9UdVdI= Date: Sun, 12 Jan 2025 07:50:38 +0900 From: Tomoaki AOKI To: Mark Johnston Cc: Konstantin Belousov , freebsd-hackers@freebsd.org Subject: Re: widening ticks Message-Id: <20250112075038.4cd7fc680400e07a32a13f1a@dec.sakura.ne.jp> In-Reply-To: References: <20250111131106.4d2657de20eeed7eef5c0b15@dec.sakura.ne.jp> <20250112043543.86b303419f954b2b287d39d1@dec.sakura.ne.jp> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.2) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4YVtz620KXz4WRM X-Spamd-Bar: ---- 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] On Sat, 11 Jan 2025 17:35:36 -0500 Mark Johnston wrote: > On Sun, Jan 12, 2025 at 04:35:43AM +0900, Tomoaki AOKI wrote: > > On Sat, 11 Jan 2025 11:34:06 -0500 > > Mark Johnston wrote: > > > > > On Sat, Jan 11, 2025 at 01:11:06PM +0900, Tomoaki AOKI wrote: > > > > On Wed, 8 Jan 2025 18:07:47 -0500 > > > > Mark Johnston wrote: > > > > > > > > > On Thu, Jan 09, 2025 at 12:18:48AM +0200, Konstantin Belousov wrote: > > > > > > On Wed, Jan 08, 2025 at 04:31:16PM -0500, Mark Johnston wrote: > > > > > > > The global "ticks" variable counts hardclock ticks, it's widely used in > > > > > > > the kernel for low-precision timekeeping. The linuxkpi provides a very > > > > > > > similar variable, "jiffies", but there's an incompatibility: the former > > > > > > > is a signed int and the latter is an unsigned long. It's not > > > > > > > particularly easy to paper over this difference, which has been > > > > > > > responsible for some nasty bugs, and modifying drivers to store the > > > > > > > jiffies value in a signed int is error-prone and a maintenance burden > > > > > > > that the linuxkpi is supposed to avoid. > > > > > > > > > > > > > > It would be nice to provide a compatible implementation of jiffies. I > > > > > > > can see a few approaches: > > > > > > > - Define a 64-bit ticks variable, say ticks64, and make hardclock() > > > > > > > update both ticks and ticks64. Then #define jiffies ticks64 on 64-bit > > > > > > > platforms. This is the simplest to implement, but it adds extra work > > > > > > > to hardclock() and is somewhat ugly. > > > > > > > - Make ticks an int64_t or a long and convert our native code > > > > > > > accordingly. This is cleaner but requires a lot of auditing to avoid > > > > > > > introducing bugs, though perhaps some code could be left unmodified, > > > > > > > implicitly truncating the value to an int. For example I think > > > > > > > sched_pctcpu_update() is fine. I've gotten an amd64 kernel to compile > > > > > > > and boot with this change, but it's hard to be confident in it. This > > > > > > > approach also has the potential downside of bloating structures that > > > > > > > store a ticks value, and it can't be MFCed. > > > > > > > - Introduce a 64-bit ticks variable, ticks64, and > > > > > > > #define ticks ((int)ticks64). This requires renaming any struct > > > > > > > fields and local vars named "ticks", of which there's a decent number, > > > > > > > but that can be done fairly mechanically. > > > > > > > > > > > > > > Is there another solution which avoids these pitfalls? If not, should > > > > > > > we go ahead with one of these approaches? If so, which one? > > > > > > > > > > > > You cannot do this in C, but can in asm: > > > > > > .data > > > > > > .globl ticksl, ticks > > > > > > .type ticksl, @object > > > > > > .type ticks, @object > > > > > > ticksl: .quad > > > > > > .size ticksl, 8 > > > > > > ticks =ticksl /* for little-endian */ > > > > > > /* ticks =ticksl + 4 for big-endian */ > > > > > > .size ticks, 4 > > > > > > > > > > > > > > > > > > Then update only ticksl in the hardclock(). > > > > > > > > > > I implemented your suggestion here: https://reviews.freebsd.org/D48383 > > > > > > > > As this is already committed to main, commenting here instead of review > > > > D48383. > > > > > > > > Maybe I'm too paranoid and overlooking something, but... > > > > > > > > *If "jiffies" in LinuxKPI is really unsigned, isn't there any > > > > possibilities that relies on its value to be larger than > > > > 0x7fffffffffffffff as a threshold? > > > > (Yes, it should be silly and non-realistic, but theoretically > > > > possible.) > > > > > > Ideally we would have > > > > > > #define jiffies ((unsigned long)ticksl) > > > > > > in the linuxkpi, but some Linux code uses "jiffies" as a struct field or > > > local variable name, so this doesn't quite work. > > > > > > In practice, the value is usually assigned to an unsigned long or used > > > as an operand where it would be implicitly promoted to an unsigned type, > > > so we don't see any incompatibilities. > > > > > > When jiffies is an int, code like the following can misbehave: > > > > > > unsigned long remain, timeout = jiffies + const; > > > ... > > > remain = timeout - jiffies; > > > if ((long)remain < 0) > > > /* timed out */ > > > > > > If (int)timeout and jiffies have different signs, as might happen close > > > to a rollover, the comparison won't work as expected. > > > > > > Linux has some macros (time_after() etc.) which are supposed to be used > > > instead of direct comparisons, but they're not always used. > > > > So ticksl should better be unsigned long if there's no reason to keep > > it signed, isn't it? > > Well, I kept it signed since it's meant to be similar in usage to ticks. > With a signed counter, you can check test whether a value has passed by > looking at the sign of the difference between ticks(l) and that value > (modulo rollover). With an unsigned counter, you need some casting, as > in the example above. > > > > > *Is anywhere checking carry (sign) bit for int on LP32? > > > > Maybe it would be the reason if "jiffies" in LinuxKPI is really > > > > unsigned. > > > > > > Could you provide an example of what you mean? > > > > Not an example of code, but for example, when ticksl is at > > 0x7fffffffffffffff (positive value), ticks shoule be 0xffffffff > > (negative value), if I read the diff correctly. > > The same thing starts happening ticksl is at 0x0000000080000000 throug > > 0x00000000ffffffff and values alike. So signs (carry bits, usually the > > leftmost bit of each) should be checked separately for ticksl and ticks. > > That's true, but I can't see why any code would care about this? While ticks is defined as (signed) int, it shoule be turnaround when it reaches at 0x7fffffff (as incrementing it causes overflow). Is ticks allowed to be minus value? My guess is that it is monotonic counter. > > Am I (hopefully) overlooking something? > > > > -- > > Tomoaki AOKI -- Tomoaki AOKI From nobody Sat Jan 11 23:00:12 2025 X-Original-To: freebsd-hackers@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 4YVvB85FJJz5jxnv for ; Sat, 11 Jan 2025 23:00:16 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (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 4YVvB831VGz4Y3s for ; Sat, 11 Jan 2025 23:00:16 +0000 (UTC) (envelope-from markjdb@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-qt1-x832.google.com with SMTP id d75a77b69052e-4679d366adeso30772271cf.1 for ; Sat, 11 Jan 2025 15:00:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736636415; x=1737241215; darn=freebsd.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:from:to:cc:subject:date:message-id :reply-to; bh=0qzIfiK2kZgFZ+jTBmAX8uSsXHiGfy3Fq8R1KvocWVc=; b=I50wBIDDYpzIubJRlBXGpz/rxGN7q8OuygL9Y0sOSaQLIlcXjbHi98zpFkcixax2Ml jV80mJGCkrK+nvnAdit0FnubyJqZZ5jKuDPgPWclYK1tphu8CaJnA0Vbv+mGIOb614hF WqLtI+XFeYg9Sf/Q6KybdKTzVbiiWOOVVhrXAkrfSfiv/9kE6JFgfxh3NRhKY+EsuayF xpJLrFoOJpCoJdkdmuxszeSgkSPl91nLoofY7IVOmprU4nbwi7nzlJq0FBortJ3BBv2w m+5uoS+EJuKkW1pb2ECqr2s3A+p4bJrqHERFXUA7ipvRDksofKFNInSjE5OvzSmS8KaG mt4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736636415; x=1737241215; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=0qzIfiK2kZgFZ+jTBmAX8uSsXHiGfy3Fq8R1KvocWVc=; b=aauoT/QsB0r/bchY0tnZpIaLhZxtRyKAQWtacZVFe49RWpPLnz7MQjidyo2KG0upaA g01Zpi4pwUx9HY53cNtP37Hg0QfdsZUWpE9F1ZWH+5ZpJL18DtFfoEMmK+GZjPSOvDk6 aTkwWIiy3qkyFDG6Vpx+XgJCotk38Rcdsy768gGv5VYdaFtzYLgeVxt7LWDd6Fnz8sL/ va/q7iUmobHQzjTUKu/ptxuVM1FkxgaMvcXG4dfzJm8OZWNzzzjqx1dxBYl14UCGvWeN uR7t6xQPU01wCQ9vJNOeczdqmBDz0FR0WRvCV70Bf525iwqbkkxexHKbYqZduD4ZvjQD dFGQ== X-Gm-Message-State: AOJu0Yz3zIQAZ0e/7Hg83NzYn/l+T47VJPvat2TQfLHV6kuDFlBPsjh/ LIo6mB4V49xFE0CmpEQTTVasmAWfwOkcHRCBkI6JwBN8jrFCZybK9tOEtA== X-Gm-Gg: ASbGncsjstykfj6ImPHsaAwGumVrY2VEWdZ3US1qtJLtTfsEiDgEQP0HAVySvKwSNsN EjcvuO5XG5YAlO7AT312EXPOSJWHDcN9YO3JLBcp5845ZCx3FOtZPl9Z83YrTkiiMD1eeNV77Nc +uPKvSXjlRd5Zm3QkOPDzAZlkqaoEzNtHLa22KTCOd7MGNZubYqwG5yBNza81qSsnl1C4ZcjH7Y lmbsXRjhtaNEKLVDPJYa1d1/NVZzQwFZBNhWs4+XpEu8jMkm+bjpbiYfzaJsN+0b9U4Cxs= X-Google-Smtp-Source: AGHT+IFXHsEbSPaUhr0JuVSkSf8vqGESY8MjZ2nXptLwJGrRezPrXVML2pd7rHNkHsJWHKpuoMa++A== X-Received: by 2002:ac8:7d8a:0:b0:467:7076:37c7 with SMTP id d75a77b69052e-46c7b06da34mr185368371cf.22.1736636414821; Sat, 11 Jan 2025 15:00:14 -0800 (PST) Received: from nuc (192-0-220-237.cpe.teksavvy.com. [192.0.220.237]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-6dfad880ec9sm24268436d6.40.2025.01.11.15.00.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 11 Jan 2025 15:00:14 -0800 (PST) Date: Sat, 11 Jan 2025 18:00:12 -0500 From: Mark Johnston To: Tomoaki AOKI Cc: freebsd-hackers@freebsd.org Subject: Re: widening ticks Message-ID: References: <20250111131106.4d2657de20eeed7eef5c0b15@dec.sakura.ne.jp> <20250112043543.86b303419f954b2b287d39d1@dec.sakura.ne.jp> <20250112075038.4cd7fc680400e07a32a13f1a@dec.sakura.ne.jp> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250112075038.4cd7fc680400e07a32a13f1a@dec.sakura.ne.jp> X-Rspamd-Queue-Id: 4YVvB831VGz4Y3s X-Spamd-Bar: ---- 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] On Sun, Jan 12, 2025 at 07:50:38AM +0900, Tomoaki AOKI wrote: > On Sat, 11 Jan 2025 17:35:36 -0500 > Mark Johnston wrote: > > > On Sun, Jan 12, 2025 at 04:35:43AM +0900, Tomoaki AOKI wrote: > > > On Sat, 11 Jan 2025 11:34:06 -0500 > > > Mark Johnston wrote: > > > > > > > On Sat, Jan 11, 2025 at 01:11:06PM +0900, Tomoaki AOKI wrote: > > > > > On Wed, 8 Jan 2025 18:07:47 -0500 > > > > > Mark Johnston wrote: > > > > > > > > > > > On Thu, Jan 09, 2025 at 12:18:48AM +0200, Konstantin Belousov wrote: > > > > > > > On Wed, Jan 08, 2025 at 04:31:16PM -0500, Mark Johnston wrote: > > > > > > > > The global "ticks" variable counts hardclock ticks, it's widely used in > > > > > > > > the kernel for low-precision timekeeping. The linuxkpi provides a very > > > > > > > > similar variable, "jiffies", but there's an incompatibility: the former > > > > > > > > is a signed int and the latter is an unsigned long. It's not > > > > > > > > particularly easy to paper over this difference, which has been > > > > > > > > responsible for some nasty bugs, and modifying drivers to store the > > > > > > > > jiffies value in a signed int is error-prone and a maintenance burden > > > > > > > > that the linuxkpi is supposed to avoid. > > > > > > > > > > > > > > > > It would be nice to provide a compatible implementation of jiffies. I > > > > > > > > can see a few approaches: > > > > > > > > - Define a 64-bit ticks variable, say ticks64, and make hardclock() > > > > > > > > update both ticks and ticks64. Then #define jiffies ticks64 on 64-bit > > > > > > > > platforms. This is the simplest to implement, but it adds extra work > > > > > > > > to hardclock() and is somewhat ugly. > > > > > > > > - Make ticks an int64_t or a long and convert our native code > > > > > > > > accordingly. This is cleaner but requires a lot of auditing to avoid > > > > > > > > introducing bugs, though perhaps some code could be left unmodified, > > > > > > > > implicitly truncating the value to an int. For example I think > > > > > > > > sched_pctcpu_update() is fine. I've gotten an amd64 kernel to compile > > > > > > > > and boot with this change, but it's hard to be confident in it. This > > > > > > > > approach also has the potential downside of bloating structures that > > > > > > > > store a ticks value, and it can't be MFCed. > > > > > > > > - Introduce a 64-bit ticks variable, ticks64, and > > > > > > > > #define ticks ((int)ticks64). This requires renaming any struct > > > > > > > > fields and local vars named "ticks", of which there's a decent number, > > > > > > > > but that can be done fairly mechanically. > > > > > > > > > > > > > > > > Is there another solution which avoids these pitfalls? If not, should > > > > > > > > we go ahead with one of these approaches? If so, which one? > > > > > > > > > > > > > > You cannot do this in C, but can in asm: > > > > > > > .data > > > > > > > .globl ticksl, ticks > > > > > > > .type ticksl, @object > > > > > > > .type ticks, @object > > > > > > > ticksl: .quad > > > > > > > .size ticksl, 8 > > > > > > > ticks =ticksl /* for little-endian */ > > > > > > > /* ticks =ticksl + 4 for big-endian */ > > > > > > > .size ticks, 4 > > > > > > > > > > > > > > > > > > > > > Then update only ticksl in the hardclock(). > > > > > > > > > > > > I implemented your suggestion here: https://reviews.freebsd.org/D48383 > > > > > > > > > > As this is already committed to main, commenting here instead of review > > > > > D48383. > > > > > > > > > > Maybe I'm too paranoid and overlooking something, but... > > > > > > > > > > *If "jiffies" in LinuxKPI is really unsigned, isn't there any > > > > > possibilities that relies on its value to be larger than > > > > > 0x7fffffffffffffff as a threshold? > > > > > (Yes, it should be silly and non-realistic, but theoretically > > > > > possible.) > > > > > > > > Ideally we would have > > > > > > > > #define jiffies ((unsigned long)ticksl) > > > > > > > > in the linuxkpi, but some Linux code uses "jiffies" as a struct field or > > > > local variable name, so this doesn't quite work. > > > > > > > > In practice, the value is usually assigned to an unsigned long or used > > > > as an operand where it would be implicitly promoted to an unsigned type, > > > > so we don't see any incompatibilities. > > > > > > > > When jiffies is an int, code like the following can misbehave: > > > > > > > > unsigned long remain, timeout = jiffies + const; > > > > ... > > > > remain = timeout - jiffies; > > > > if ((long)remain < 0) > > > > /* timed out */ > > > > > > > > If (int)timeout and jiffies have different signs, as might happen close > > > > to a rollover, the comparison won't work as expected. > > > > > > > > Linux has some macros (time_after() etc.) which are supposed to be used > > > > instead of direct comparisons, but they're not always used. > > > > > > So ticksl should better be unsigned long if there's no reason to keep > > > it signed, isn't it? > > > > Well, I kept it signed since it's meant to be similar in usage to ticks. > > With a signed counter, you can check test whether a value has passed by > > looking at the sign of the difference between ticks(l) and that value > > (modulo rollover). With an unsigned counter, you need some casting, as > > in the example above. > > > > > > > *Is anywhere checking carry (sign) bit for int on LP32? > > > > > Maybe it would be the reason if "jiffies" in LinuxKPI is really > > > > > unsigned. > > > > > > > > Could you provide an example of what you mean? > > > > > > Not an example of code, but for example, when ticksl is at > > > 0x7fffffffffffffff (positive value), ticks shoule be 0xffffffff > > > (negative value), if I read the diff correctly. > > > The same thing starts happening ticksl is at 0x0000000080000000 throug > > > 0x00000000ffffffff and values alike. So signs (carry bits, usually the > > > leftmost bit of each) should be checked separately for ticksl and ticks. > > > > That's true, but I can't see why any code would care about this? > > While ticks is defined as (signed) int, it shoule be turnaround when it > reaches at 0x7fffffff (as incrementing it causes overflow). > Is ticks allowed to be minus value? My guess is that it is monotonic > counter. Yes, INT_MAX ticks elapse in approximately 25 days at 1000Hz. In fact, ticks is initialized to INT_MAX - in subr_param.c so that it wraps around shortly after boot, after which it is negative. Kernel code should not care about the sign of ticks. From nobody Sun Jan 12 02:16:51 2025 X-Original-To: freebsd-hackers@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 4YW0dy00MBz5kK3W for ; Sun, 12 Jan 2025 03:06:14 +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 4YW0dw363mz4snT for ; Sun, 12 Jan 2025 03:06:12 +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=nlTuIpWz; 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; dmarc=pass (policy=none) header.from=dec.sakura.ne.jp Received: from kalamity.joker.local (124-18-43-234.area1a.commufa.jp [124.18.43.234]) (authenticated bits=0) by www121.sakura.ne.jp (8.17.1/8.17.1/[SAKURA-WEB]/20201212) with ESMTPA id 50C2Gp4Y076679 for ; Sun, 12 Jan 2025 11:16: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=1736648212; bh=GTndGheZIDlteI+ASrC5hDsYCld/fBc34N9v8PxMrH0=; h=Date:From:To:Subject:In-Reply-To:References; b=nlTuIpWzp+ktI89lu7C7nRuXR1wpGZbZFW1RrxJy/zkWpTK+sRs9LMZRpv7fAymMI sZyqmHXo6w+S5M94H9+wE3NAYWXNgOTxQHJtbLMHLo81FwSDD1QW7tUo/hyMQ87s6K yXQgF/Wnh0NtWTx4ZhRLz/GRQiHoaCMgn5gjiy40= Date: Sun, 12 Jan 2025 11:16:51 +0900 From: Tomoaki AOKI To: freebsd-hackers@freebsd.org Subject: Re: widening ticks Message-Id: <20250112111651.e76aea0843ac8f85043c7f10@dec.sakura.ne.jp> In-Reply-To: References: <20250111131106.4d2657de20eeed7eef5c0b15@dec.sakura.ne.jp> <20250112043543.86b303419f954b2b287d39d1@dec.sakura.ne.jp> <20250112075038.4cd7fc680400e07a32a13f1a@dec.sakura.ne.jp> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.2) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4YW0dw363mz4snT X-Spamd-Bar: ++ X-Spamd-Result: default: False [2.20 / 15.00]; URIBL_RED(3.50)[dec.sakura.ne.jp:dkim]; SUSPICIOUS_URL_IN_SUSPICIOUS_MESSAGE(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; MV_CASE(0.50)[]; HAS_ANON_DOMAIN(0.10)[]; BAD_REP_POLICIES(0.10)[]; MIME_GOOD(-0.10)[text/plain]; ONCE_RECEIVED(0.10)[]; DMARC_POLICY_ALLOW(0.00)[dec.sakura.ne.jp,none]; DKIM_TRACE(0.00)[dec.sakura.ne.jp:+]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; GREYLIST(0.00)[pass,body]; R_DKIM_ALLOW(0.00)[dec.sakura.ne.jp:s=s2405]; HAS_ORG_HEADER(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP]; MIME_TRACE(0.00)[0:+]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; R_SPF_ALLOW(0.00)[+ip4:153.125.133.16/28:c]; RCPT_COUNT_ONE(0.00)[1] Replying to ML only, as Mark's gmail address seems to block previous one. On Sat, 11 Jan 2025 18:00:12 -0500 Mark Johnston wrote: > On Sun, Jan 12, 2025 at 07:50:38AM +0900, Tomoaki AOKI wrote: > > On Sat, 11 Jan 2025 17:35:36 -0500 > > Mark Johnston wrote: > > > > > On Sun, Jan 12, 2025 at 04:35:43AM +0900, Tomoaki AOKI wrote: > > > > On Sat, 11 Jan 2025 11:34:06 -0500 > > > > Mark Johnston wrote: > > > > > > > > > On Sat, Jan 11, 2025 at 01:11:06PM +0900, Tomoaki AOKI wrote: > > > > > > On Wed, 8 Jan 2025 18:07:47 -0500 > > > > > > Mark Johnston wrote: > > > > > > > > > > > > > On Thu, Jan 09, 2025 at 12:18:48AM +0200, Konstantin Belousov wrote: > > > > > > > > On Wed, Jan 08, 2025 at 04:31:16PM -0500, Mark Johnston wrote: > > > > > > > > > The global "ticks" variable counts hardclock ticks, it's widely used in > > > > > > > > > the kernel for low-precision timekeeping. The linuxkpi provides a very > > > > > > > > > similar variable, "jiffies", but there's an incompatibility: the former > > > > > > > > > is a signed int and the latter is an unsigned long. It's not > > > > > > > > > particularly easy to paper over this difference, which has been > > > > > > > > > responsible for some nasty bugs, and modifying drivers to store the > > > > > > > > > jiffies value in a signed int is error-prone and a maintenance burden > > > > > > > > > that the linuxkpi is supposed to avoid. > > > > > > > > > > > > > > > > > > It would be nice to provide a compatible implementation of jiffies. I > > > > > > > > > can see a few approaches: > > > > > > > > > - Define a 64-bit ticks variable, say ticks64, and make hardclock() > > > > > > > > > update both ticks and ticks64. Then #define jiffies ticks64 on 64-bit > > > > > > > > > platforms. This is the simplest to implement, but it adds extra work > > > > > > > > > to hardclock() and is somewhat ugly. > > > > > > > > > - Make ticks an int64_t or a long and convert our native code > > > > > > > > > accordingly. This is cleaner but requires a lot of auditing to avoid > > > > > > > > > introducing bugs, though perhaps some code could be left unmodified, > > > > > > > > > implicitly truncating the value to an int. For example I think > > > > > > > > > sched_pctcpu_update() is fine. I've gotten an amd64 kernel to compile > > > > > > > > > and boot with this change, but it's hard to be confident in it. This > > > > > > > > > approach also has the potential downside of bloating structures that > > > > > > > > > store a ticks value, and it can't be MFCed. > > > > > > > > > - Introduce a 64-bit ticks variable, ticks64, and > > > > > > > > > #define ticks ((int)ticks64). This requires renaming any struct > > > > > > > > > fields and local vars named "ticks", of which there's a decent number, > > > > > > > > > but that can be done fairly mechanically. > > > > > > > > > > > > > > > > > > Is there another solution which avoids these pitfalls? If not, should > > > > > > > > > we go ahead with one of these approaches? If so, which one? > > > > > > > > > > > > > > > > You cannot do this in C, but can in asm: > > > > > > > > .data > > > > > > > > .globl ticksl, ticks > > > > > > > > .type ticksl, @object > > > > > > > > .type ticks, @object > > > > > > > > ticksl: .quad > > > > > > > > .size ticksl, 8 > > > > > > > > ticks =ticksl /* for little-endian */ > > > > > > > > /* ticks =ticksl + 4 for big-endian */ > > > > > > > > .size ticks, 4 > > > > > > > > > > > > > > > > > > > > > > > > Then update only ticksl in the hardclock(). > > > > > > > > > > > > > > I implemented your suggestion here: https://reviews.freebsd.org/D48383 > > > > > > > > > > > > As this is already committed to main, commenting here instead of review > > > > > > D48383. > > > > > > > > > > > > Maybe I'm too paranoid and overlooking something, but... > > > > > > > > > > > > *If "jiffies" in LinuxKPI is really unsigned, isn't there any > > > > > > possibilities that relies on its value to be larger than > > > > > > 0x7fffffffffffffff as a threshold? > > > > > > (Yes, it should be silly and non-realistic, but theoretically > > > > > > possible.) > > > > > > > > > > Ideally we would have > > > > > > > > > > #define jiffies ((unsigned long)ticksl) > > > > > > > > > > in the linuxkpi, but some Linux code uses "jiffies" as a struct field or > > > > > local variable name, so this doesn't quite work. > > > > > > > > > > In practice, the value is usually assigned to an unsigned long or used > > > > > as an operand where it would be implicitly promoted to an unsigned type, > > > > > so we don't see any incompatibilities. > > > > > > > > > > When jiffies is an int, code like the following can misbehave: > > > > > > > > > > unsigned long remain, timeout = jiffies + const; > > > > > ... > > > > > remain = timeout - jiffies; > > > > > if ((long)remain < 0) > > > > > /* timed out */ > > > > > > > > > > If (int)timeout and jiffies have different signs, as might happen close > > > > > to a rollover, the comparison won't work as expected. > > > > > > > > > > Linux has some macros (time_after() etc.) which are supposed to be used > > > > > instead of direct comparisons, but they're not always used. > > > > > > > > So ticksl should better be unsigned long if there's no reason to keep > > > > it signed, isn't it? > > > > > > Well, I kept it signed since it's meant to be similar in usage to ticks. > > > With a signed counter, you can check test whether a value has passed by > > > looking at the sign of the difference between ticks(l) and that value > > > (modulo rollover). With an unsigned counter, you need some casting, as > > > in the example above. > > > > > > > > > *Is anywhere checking carry (sign) bit for int on LP32? > > > > > > Maybe it would be the reason if "jiffies" in LinuxKPI is really > > > > > > unsigned. > > > > > > > > > > Could you provide an example of what you mean? > > > > > > > > Not an example of code, but for example, when ticksl is at > > > > 0x7fffffffffffffff (positive value), ticks shoule be 0xffffffff > > > > (negative value), if I read the diff correctly. > > > > The same thing starts happening ticksl is at 0x0000000080000000 throug > > > > 0x00000000ffffffff and values alike. So signs (carry bits, usually the > > > > leftmost bit of each) should be checked separately for ticksl and ticks. > > > > > > That's true, but I can't see why any code would care about this? > > > > While ticks is defined as (signed) int, it shoule be turnaround when it > > reaches at 0x7fffffff (as incrementing it causes overflow). > > Is ticks allowed to be minus value? My guess is that it is monotonic > > counter. > > Yes, INT_MAX ticks elapse in approximately 25 days at 1000Hz. In fact, > ticks is initialized to INT_MAX - in subr_param.c so that > it wraps around shortly after boot, after which it is negative. > > Kernel code should not care about the sign of ticks. Thanks! I've overlooked it. BTW, does tickl restricted with INT_MAX, too? (In detail, although tickl has the type long, but actually the range of the values used are restricted with INT_MAX?) -- Tomoaki AOKI From nobody Sun Jan 12 03:35:51 2025 X-Original-To: freebsd-hackers@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 4YW1JC1rkGz5kLqp for ; Sun, 12 Jan 2025 03:35:55 +0000 (UTC) (envelope-from yuri@FreeBSD.org) Received: from shell1.rawbw.com (shell1.rawbw.com [198.144.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id 4YW1JB3RJcz4wX9 for ; Sun, 12 Jan 2025 03:35:54 +0000 (UTC) (envelope-from yuri@FreeBSD.org) Authentication-Results: mx1.freebsd.org; dkim=none; spf=softfail (mx1.freebsd.org: 198.144.192.42 is neither permitted nor denied by domain of yuri@FreeBSD.org) smtp.mailfrom=yuri@FreeBSD.org; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=freebsd.org (policy=none) Received: from [192.168.5.3] (c-98-42-44-116.hsd1.ca.comcast.net [98.42.44.116]) (authenticated bits=0) by shell1.rawbw.com (8.15.1/8.15.1) with ESMTPSA id 50C3ZqCn062507 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Sat, 11 Jan 2025 19:35:53 -0800 (PST) (envelope-from yuri@FreeBSD.org) X-Authentication-Warning: shell1.rawbw.com: Host c-98-42-44-116.hsd1.ca.comcast.net [98.42.44.116] claimed to be [192.168.5.3] Message-ID: Date: Sat, 11 Jan 2025 19:35:51 -0800 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: Freebsd hackers list From: Yuri Subject: pthread_mutex_trylock crashes because _get_curthread() returns null Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4YW1JB3RJcz4wX9 X-Spamd-Bar: + X-Spamd-Result: default: False [1.02 / 15.00]; VIOLATED_DIRECT_SPF(3.50)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-0.91)[-0.907]; NEURAL_HAM_SHORT(-0.78)[-0.781]; MIME_GOOD(-0.10)[text/plain]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : No valid SPF, No valid DKIM,none]; ONCE_RECEIVED(0.10)[]; RCVD_NO_TLS_LAST(0.10)[]; XM_UA_NO_VERSION(0.01)[]; RCVD_COUNT_ONE(0.00)[1]; TO_DN_ALL(0.00)[]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FREEFALL_USER(0.00)[yuri]; RCVD_VIA_SMTP_AUTH(0.00)[]; MIME_TRACE(0.00)[0:+]; R_SPF_SOFTFAIL(0.00)[~all:c]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:7961, ipnet:198.144.192.0/23, country:US]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@FreeBSD.org]; TO_DOM_EQ_FROM_DOM(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; HAS_XAW(0.00)[] I am trying to understand this crash: 614│ int 615│ __Tthr_mutex_trylock(pthread_mutex_t *mutex) 616│ { 617│         struct pthread *curthread; 618│         struct pthread_mutex *m; 619│         uint32_t id; 620│         int ret, robust; 621│ 622│         ret = check_and_init_mutex(mutex, &m); 623│         if (ret != 0) 624│                 return (ret); 625│         curthread = _get_curthread(); 626│         id = TID(curthread); 627│         if (m->m_flags & PMUTEX_FLAG_PRIVATE) 628├───────────────> THR_CRITICAL_ENTER(curthread); Program received signal SIGSEGV, Segmentation fault. Address not mapped to object. __Tthr_mutex_trylock (mutex=) at /disk-samsung/freebsd-src/lib/libthr/thread/thr_mutex.c:628 628                     THR_CRITICAL_ENTER(curthread); The crash occurs at the program startup within the pthread_mutex_trylock() function. The immediate cause is that _get_curthread() returned null in curthread. Testcase: the port databases/qdrant at rev. e7cee8d22daf5b6360238cad603ca9f96ecd87fd (at version 1.12.5). How can it be that _get_curthread() returns null? Shouldn't current thread be always defined? 14.2-STABLE Thanks, Yuri From nobody Sun Jan 12 05:52:19 2025 X-Original-To: freebsd-hackers@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 4YW4Kw4zvsz5kXcn for ; Sun, 12 Jan 2025 05:52:36 +0000 (UTC) (envelope-from freebsd-hackers-freebsd-org952@ketas.si.pri.ee) Received: from mail.ketas.si.pri.ee (d004-fea2-0bff-021e-13e8-8437-07d0-2001.dyn.estpak.ee [IPv6:2001:7d0:8437:13e8:21e:bff:fea2:d004]) (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 4YW4Kv68f6z596n for ; Sun, 12 Jan 2025 05:52:35 +0000 (UTC) (envelope-from freebsd-hackers-freebsd-org952@ketas.si.pri.ee) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=ketas.si.pri.ee header.s=ketas-si-pri-ee-20240416002854-4096 header.b=P0R1oDuR; spf=pass (mx1.freebsd.org: domain of freebsd-hackers-freebsd-org952@ketas.si.pri.ee designates 2001:7d0:8437:13e8:21e:bff:fea2:d004 as permitted sender) smtp.mailfrom=freebsd-hackers-freebsd-org952@ketas.si.pri.ee; dmarc=pass (policy=reject) header.from=ketas.si.pri.ee X-Original-To: freebsd-hackers@freebsd.org DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ketas.si.pri.ee; s=ketas-si-pri-ee-20240416002854-4096; t=1736661153; bh=CwSgrLJZsu1IRDAKNKFGz9WOnya3X6HxJQnntdhdVCk=; h=Date:From:To:Subject; b=P0R1oDuR49kVvkFWWR+v01Zwm6t1EXwjXE7G86M74aSXzCw6JM+4PL87wgFQTJ4r6 U4DqNhPG3jXH8cMrxJvqriCs83rgccMsazXcpv+f7YmWLUfue32U0Bdz8T12BVkQEI jtYisH0ffGAwLKKtHqCXwNXZUShwsmTyFV0+G2aI5O1k7CwaxcA7XI4YE/76ZLCQ+r AWhaa+8WVtrK4g4BJvE80dHR47zW7vCdwFmXUTFmGzSDduN0NsI+6+R5Kkxx1PipLI jBSJQSuR29NFRYTBjxKRu0nXd0p+slb34Pb52bjSnxaUwj0WTjdp5jXMDosrCEedkf Hpe+/D/bdaiVkbGivllwJzhp17cZ65f7sYzIcU+xsJvFuGQXAB6KwK+WFc/5IvUKEa UKeAoeEPn+YKAilUDN/dBxHnISsSumDwOJOnEOmt1ZZ2OoMCgX/slTcXshvacWw1zc boqNjqHle1GXLslynsMDmacXlxGi4VrEvT0AoPALeod9sLkm9zjxvcJLsEX7bWO8W3 nl9bvnxBJz1MN3Uic4nROLuTHNeVDNWDbMqXJAqPyhj0LUpUMV0W3KDpdD5DF12apk BcZJS0iMKH0nD+DXP+Jwl3eJkueZ6l5aznxuE22nf26WKVNWswnSoWXw6oMqbfF9DT /MuBEKsrxWvxvVUu+YDscmuA= Received: from [IPv6:::1] (0114-0000-0000-0000-13c8-8437-07d0-2001.dyn.estpak.ee [IPv6:2001:7d0:8437:13c8::114]) (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 mail.ketas.si.pri.ee (Postfix) with ESMTPSA id BE0DC58862C for ; Sun, 12 Jan 2025 07:52:33 +0200 (EET) Date: Sun, 12 Jan 2025 07:52:19 +0200 From: Sulev-Madis Silber To: freebsd-hackers@FreeBSD.org Subject: =?US-ASCII?Q?serial_port_data_corruption=2C_possible_ke?= =?US-ASCII?Q?rnel_/_memory_corruption_outside_of_that?= User-Agent: K-9 Mail for Android Message-ID: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4YW4Kv68f6z596n X-Spamd-Bar: / X-Spamd-Result: default: False [0.32 / 15.00]; HFILTER_HOSTNAME_5(3.00)[d004-fea2-0bff-021e-13e8-8437-07d0-2001.dyn.estpak.ee]; SUBJ_EXCESS_QP(1.20)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.98)[-0.981]; DMARC_POLICY_ALLOW(-0.50)[ketas.si.pri.ee,reject]; R_SPF_ALLOW(-0.20)[+ip6:2001:7d0:8437:1300::/56]; R_DKIM_ALLOW(-0.20)[ketas.si.pri.ee:s=ketas-si-pri-ee-20240416002854-4096]; ONCE_RECEIVED(0.10)[]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:3249, ipnet:2001:7d0::/32, country:EE]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_TLS_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@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-hackers@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[ketas.si.pri.ee:+] right list? i have issue where multiple people report usb serial ports behave weirdly = and they mix up their input buffers and output buffers all the info is in https://bugs=2Efreebsd=2Eorg/bugzilla/show_bug=2Ecgi?id= =3D273566 i'm apparently incapable to understanding, let alone fixing it data seems to jump buffers, even end up in another console, in case of phy= sical sc/vt tty on box, as a result it also feels as if kernel corrupts in general=2E this affects multiple ar= chs i think i've uncovered bug in some usb serial drivers, in ucom, usb? i don= 't know was already suggested kasan kernel but have to look where to run it, need = special test hw for this problem appears if lot of data starts suddenly flowing through ports, whic= h might be unusual usecase for them and therefore triggers, unsure, what, b= uffer overflow? something just blows up there and i don't know what From nobody Sun Jan 12 07:23:00 2025 X-Original-To: freebsd-hackers@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 4YW6Lr4tptz5kg0v for ; Sun, 12 Jan 2025 07:23:32 +0000 (UTC) (envelope-from cedric.blancher@gmail.com) Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) (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 4YW6Lq4npQz443K for ; Sun, 12 Jan 2025 07:23:31 +0000 (UTC) (envelope-from cedric.blancher@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b="Th/ORto7"; spf=pass (mx1.freebsd.org: domain of cedric.blancher@gmail.com designates 2607:f8b0:4864:20::630 as permitted sender) smtp.mailfrom=cedric.blancher@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-pl1-x630.google.com with SMTP id d9443c01a7336-2167141dfa1so57896265ad.1 for ; Sat, 11 Jan 2025 23:23:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736666610; x=1737271410; darn=freebsd.org; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=H65W9SGeFtcW9Dv0c0qlRC3/WsaCjJPmFHozs1vsEMs=; b=Th/ORto77LabSGpOPW3OFW4aOY4Y2uK5w8tZLsFOYSPfxKCwJuVNjB/uiaa57XAOrf FC7lTJSaUwX2hGLT49AtvZ5EGmsjCB4vFe+0eQ/nn2+1ZKIQKQMY+7XvWLbFyiQUV0ZS YQ1ikFNuXpQKVYmfmWhplclaTUV7YPoTnbJV606yTwya8GEanPzpWHI2+F9+iqsutJdw TlqfPPAGxk/Nl8aDLvUQ8f3JJGtciuzFaMh5YqKL89wCTXYxncAZ9Fyo5DxUvQhzLqJw BIZZn3zJ8jgC0nxguOrnqjHHxCQi+iyb3SHyz0OhO3rtR/UzwdKcCNuj4NM6JGcWN6Ky qBVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736666610; x=1737271410; h=content-transfer-encoding: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=H65W9SGeFtcW9Dv0c0qlRC3/WsaCjJPmFHozs1vsEMs=; b=h/3mq/FQavsziyyE9QUCEJGMUay/s+6ednVUJGGUKKiKOjHDEw/ygvu6yyLb1gZvxS Bkj09o+j+BUR+nlfKjRdb8piTavCsIRwTJwEjayKzBDQxe8/HYngiNSD/Wh1h5NgO94f Qcy6drDJiL9Mi6DiqgnJsRhV6DYtigJ4BRHigpyEsTPHGEcqzCtrXOYzJBHQLORw6bXH ph1CH2ID7in1kjhOCS2YKvQGCYLr1dJZFff4vZ4nIULicnTaJAzFCga67aVD6K0WjybR Q4YTWD+AGYSNPBdb9izS5vlwPXTQPLp0KOWUeQPx/tDfBgjxxafjgjw+4YSaQkJgEX6S aOAg== X-Gm-Message-State: AOJu0YxypMeopB8DHxKvUYd5HAYpkXo5WKNlDfKpdPvk9XtmyhZNUqxQ l3if4F6zlLdzcAcIlHyAbHJcunqoOuHBTKAzS1XQ7pbwMDLfI3765aopxO7tQlKtpkYlFuSu4Ym hNKvereftv4wmN1Dlb6M9bVn9QapRIttR X-Gm-Gg: ASbGncv8ndD+/mPw5q4ASX4Rmq2tceu1qI2G4gV72xW1ZMf2FfvZj6L7wA0cyXh/P8S JKfkcov/Xy2/+N1q35uTBWP16alGXYXSkNRp0oIU= X-Google-Smtp-Source: AGHT+IFojv4qf1856BssPiITPQ4LrjcIz7/fQ1sYKGRKy4uDdRtTzrpZC13680glXBf2s1ABg4ytVsxEpGHxSfxqYrQ= X-Received: by 2002:a17:90b:1c0a:b0:2ef:7be8:e987 with SMTP id 98e67ed59e1d1-2f5545de989mr18854865a91.12.1736666610080; Sat, 11 Jan 2025 23:23:30 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 References: In-Reply-To: From: Cedric Blancher Date: Sun, 12 Jan 2025 08:23:00 +0100 X-Gm-Features: AbW1kvYttmrevaK9CdcoTkCC_dAf3vPTW4NKF3WjVcfokuG_PU01S6w5rcpeqb4 Message-ID: Subject: Re: WRITE_SAME support in FreeBSD nfsd NFSv4.1 mode? To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4YW6Lq4npQz443K X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.95 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.95)[-0.952]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_FROM(0.00)[gmail.com]; RCPT_COUNT_ONE(0.00)[1]; FREEMAIL_ENVFROM(0.00)[gmail.com]; TAGGED_FROM(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; MISSING_XM_UA(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MID_RHS_MATCH_FROMTLD(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; RCVD_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::630:from] On Fri, 10 Jan 2025 at 16:02, Alan Somers wrote: > > On Thu, Jan 9, 2025 at 5:31=E2=80=AFPM Dan Shelton wrote: > > > > Hello! > > > > Does FreeBSD nfsd support the WRITE_SAME request in NFSv4.1 mode? > > > > Dan > > -- > > Dan Shelton - Cluster Specialist Win/Lin/Bsd > > Out of curiosity, what is your use case? As discussed in the linux-nfs@ list, is a typical "big data" and database accelerator, for example fast pattern fill (1 WRITE_SAME command over the write, compared to commands with data block, where is typically > 200 average), or just zero fill for blocks. It's basically reducing network traffic dramatically. Windows SMB 3.0 already supports that, and is a main selling point for M$ to keep database people on the W$ platform. They even added several Windows syscalls like https://learn.microsoft.com/en-us/windows/win32/api/winioctl/ni-winioctl-fs= ctl_set_zero_data Ced --=20 Cedric Blancher [https://plus.google.com/u/0/+CedricBlancher/] Institute Pasteur From nobody Sun Jan 12 10:09:02 2025 X-Original-To: freebsd-hackers@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 4YWB2Y21Bsz5kPqH for ; Sun, 12 Jan 2025 10:09:41 +0000 (UTC) (envelope-from cedric.blancher@gmail.com) Received: from mail-pj1-x1030.google.com (mail-pj1-x1030.google.com [IPv6:2607:f8b0:4864:20::1030]) (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 4YWB2X3nK0z4KP1 for ; Sun, 12 Jan 2025 10:09:40 +0000 (UTC) (envelope-from cedric.blancher@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=PgZlLToB; spf=pass (mx1.freebsd.org: domain of cedric.blancher@gmail.com designates 2607:f8b0:4864:20::1030 as permitted sender) smtp.mailfrom=cedric.blancher@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-pj1-x1030.google.com with SMTP id 98e67ed59e1d1-2ef72924e53so5731361a91.3 for ; Sun, 12 Jan 2025 02:09:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736676578; x=1737281378; darn=freebsd.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=UK1XT97FosbuMK8u+yNCv6Yj3V3jNjg/PiMiOOms+ME=; b=PgZlLToBtqMR0Zg0wZ0OuXLNLPf+db1BrS7XM+9DFAzGOB/XddYQ7trcHW0ZWzoxJy RcrJdcZimDpNoYOFSYxaHeTN083hVbwElyEJXfFsm3xOlfsI5NyA0/JzUujp6yBa4rjp CUkd+jPyn53CacvC9yjOiCayBKCvbOHMrUvSjuxX0t5tYnlRO0aQy8mOjq5onDgE3LH9 7Y0h7XAH6GLY+WzUie/OOC68ZsCjCcoW7turmO2yB88PnFmKps3UJx/JWxZKb38ys0Tz 2sXjDsioxaG2BbPXUHLrUSsHr0C2J8ZnF2dJcGB1I7ro/8g8D9AcAhn1zADkBDJmDh85 RVrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736676578; x=1737281378; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=UK1XT97FosbuMK8u+yNCv6Yj3V3jNjg/PiMiOOms+ME=; b=RIrLWA3GNyqxRDkE5Z8RiLGbpYlUIhMiTNRk9V0bDWOavZFMsBZRhXcTwBGZCmqrOO IrOG7csGLywxWbGrW8emyoer3UeOrrQbFalvPnyqa9OQRnow5X6NV1APBxUgNJAxLe9p oBC+DtwNwMCO7dtqrhadQPyw9lTcZfGJTfgUkAqjlX2Qy8TreEUgCOro0cU6CDNK4lwn ul4g2DVjJ8sFvGwDOPTt8tWbiRqbxOw99RK3bXC5u1BRj5605AxUszy6Iqq6ATOAjxvv oUwvCeLYYRJKErzH3FLommL706aJXwcwd0goF6h9PtidKO5tUQeIr4OSqZ/w/rdF7dCH S3cw== X-Gm-Message-State: AOJu0YxoYFkW7VTbe4ylPudvoEhQaRFVs+fs2ajkGkJ89I837MdjpX74 9Sxq8oFVsfD7CjGOkMWT3RsPAQAivednogWSGunQHDxOV2ZZ8CZhLGKMKKS/rvTHQsb0+21Tmgq 2CzgeTV+eeGo0B+N5afvvNJaX8EX2FAZ3 X-Gm-Gg: ASbGncsfMDD/5bmv6/CoeNZ2XR6KeXorLOTOcMpCRVtQGN9OqUHyH9EM6qwq3/ape8z M2Jpb3SJbgcu5oAZy90vwHfSsLZ7OmvGVBBAqcOw= X-Google-Smtp-Source: AGHT+IGHNVtJFnpD+gTyEZNLe/Hamf+ZP1g0sKnp6sGbhex25RFWtOJ7HekuQxYE22aMfDN9l4WDjn7lloB1fLrZG6I= X-Received: by 2002:a17:90b:2e41:b0:2ee:a4f2:b307 with SMTP id 98e67ed59e1d1-2f548e9ca14mr24134293a91.4.1736676578591; Sun, 12 Jan 2025 02:09:38 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 From: Cedric Blancher Date: Sun, 12 Jan 2025 11:09:02 +0100 X-Gm-Features: AbW1kvb-cINirzvsd2BRUH8rdtHKxV2jmDyMlMN_MjKSmjpqDJtEUcuuOT7G504 Message-ID: Subject: FreeBSD NFSv4.1 nfsd, named attribute support (OPENATTR)? To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4YWB2X3nK0z4KP1 X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.89 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.89)[-0.889]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_FROM(0.00)[gmail.com]; ARC_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; TAGGED_FROM(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FROM_HAS_DN(0.00)[]; MISSING_XM_UA(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MID_RHS_MATCH_FROMTLD(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; RCVD_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::1030:from] Good morning! Does FreeBSD NFSv4.1 nfsd support named attributes (e.g. OPENATTR), per https://datatracker.ietf.org/doc/html/rfc5661#section-5.3 ZFS and Solaris UFS support named attributes (via O_XATTR), does FreeBSD do it too? Ced -- Cedric Blancher [https://plus.google.com/u/0/+CedricBlancher/] Institute Pasteur From nobody Sun Jan 12 11:31:08 2025 X-Original-To: freebsd-hackers@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 4YWCrv5zZyz5kWkL for ; Sun, 12 Jan 2025 11:31:27 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4YWCrt5wtmz4RdZ; Sun, 12 Jan 2025 11:31:26 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.18.1/8.18.1) with ESMTP id 50CBV8xK008484; Sun, 12 Jan 2025 13:31:11 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 50CBV8xK008484 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 50CBV8rg008483; Sun, 12 Jan 2025 13:31:08 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 12 Jan 2025 13:31:08 +0200 From: Konstantin Belousov To: Yuri Cc: Freebsd hackers list Subject: Re: pthread_mutex_trylock crashes because _get_curthread() returns null Message-ID: References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=4.0.1 X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on tom.home X-Rspamd-Queue-Id: 4YWCrt5wtmz4RdZ X-Spamd-Bar: ---- 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:6939, ipnet:2001:470::/32, country:US] On Sat, Jan 11, 2025 at 07:35:51PM -0800, Yuri wrote: > I am trying to understand this crash: > > 614│ int > 615│ __Tthr_mutex_trylock(pthread_mutex_t *mutex) > 616│ { > 617│         struct pthread *curthread; > 618│         struct pthread_mutex *m; > 619│         uint32_t id; > 620│         int ret, robust; > 621│ > 622│         ret = check_and_init_mutex(mutex, &m); > 623│         if (ret != 0) > 624│                 return (ret); > 625│         curthread = _get_curthread(); > 626│         id = TID(curthread); > 627│         if (m->m_flags & PMUTEX_FLAG_PRIVATE) > 628├───────────────> THR_CRITICAL_ENTER(curthread); > > Program received signal SIGSEGV, Segmentation fault. > Address not mapped to object. > __Tthr_mutex_trylock (mutex=) at > /disk-samsung/freebsd-src/lib/libthr/thread/thr_mutex.c:628 > 628                     THR_CRITICAL_ENTER(curthread); > > The crash occurs at the program startup within the pthread_mutex_trylock() > function. > > The immediate cause is that _get_curthread() returned null in curthread. > > > Testcase: the port databases/qdrant at rev. > e7cee8d22daf5b6360238cad603ca9f96ecd87fd (at version 1.12.5). > > > How can it be that _get_curthread() returns null? > > Shouldn't current thread be always defined? The following patch should help, please check commit fb77577e7a4995f038a5d28f42d4c3771e536fdb Author: Konstantin Belousov Date: Sun Jan 12 13:28:52 2025 +0200 pthread_mutex_trylock(): init libthr if needed Sponsored by: The FreeBSD Foundation MFC after: 1 week diff --git a/lib/libthr/thread/thr_mutex.c b/lib/libthr/thread/thr_mutex.c index ca8971cc720a..32bdc4afe65f 100644 --- a/lib/libthr/thread/thr_mutex.c +++ b/lib/libthr/thread/thr_mutex.c @@ -619,6 +619,7 @@ __Tthr_mutex_trylock(pthread_mutex_t *mutex) uint32_t id; int ret, robust; + _thr_check_init(); ret = check_and_init_mutex(mutex, &m); if (ret != 0) return (ret); From nobody Sun Jan 12 14:17:50 2025 X-Original-To: freebsd-hackers@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 4YWHYQ61ngz5klLR for ; Sun, 12 Jan 2025 14:18:18 +0000 (UTC) (envelope-from joel.bertrand@systella.fr) Received: from rayleigh.systella.fr (rayleigh.systella.fr [IPv6:2a0a:1c84:1000:a00::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "*.systella.fr", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4YWHYP6VGLz4hTn for ; Sun, 12 Jan 2025 14:18:17 +0000 (UTC) (envelope-from joel.bertrand@systella.fr) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=systella.fr header.s=mail header.b=FhXaKL6w; spf=pass (mx1.freebsd.org: domain of joel.bertrand@systella.fr designates 2a0a:1c84:1000:a00::2 as permitted sender) smtp.mailfrom=joel.bertrand@systella.fr; dmarc=pass (policy=reject) header.from=systella.fr DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=systella.fr; s=mail; t=1736691478; bh=T7X5nvr8wQ77d4YZFqWjHY5M1yCJ2ejT1MQf1vYsMDc=; h=To:From:Subject:Date:From; b=FhXaKL6wD1T6f9LO7MPfxuMsU6Y+CP8+bP6tMVx/US2cGJDKxhcQMratE+Qn++L1Z MaHd5zJ0/gn90PuBhxkILaXwkkidr0bCMDw6hnPQucPTHBefM2LW0+1PMugBLvdhAA r7Wr6QhgiV/Vtg/65LaVvphNGL0xhiLKOba7eIm+SvTRkwFo6CgmvrvbHPQ9prxyj2 dio/brA1wUp34Tajv04si6ur8od5gc4Rsee78GbBOnal7RZrCjSDtb10adJzqBUQZO U1CQqT5+onZLzWmBjwHlSezKkAh4khJzp+bHU8C0vF4+qUPxqDICkCdTJP8FymcKRB xrdlTh7GeHdwQ== Received: from [192.168.10.103] (hilbert.systella.fr [192.168.10.103]) (authenticated bits=0) by rayleigh.systella.fr (8.18.1/8.18.1/Debian-6) with ESMTPSA id 50CEHvqa029519 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Sun, 12 Jan 2025 15:17:58 +0100 To: Eduardo Morras via freebsd-hackers From: =?UTF-8?Q?BERTRAND_Jo=c3=abl?= Subject: [14.2] No console Autocrypt: addr=joel.bertrand@systella.fr; prefer-encrypt=mutual; keydata= mDMEZRwX3xYJKwYBBAHaRw8BAQdAPnfO4wC5CMbkYaOioVYbTVmx5dnKJwvYZ8EKDFyZGyO0 KkJFUlRSQU5EIEpvw6tsIDxqb2VsLmJlcnRyYW5kQHN5c3RlbGxhLmZyPoiMBBAWCgA+BYJl HBffBAsJBwgJkMVb+z+YwtcIAxUICgQWAAIBAhkBApsDAh4BFiEEI/DFvIjrAtkVxM55xVv7 P5jC1wgAADaKAQCkdx4kqKvHPhJGYGrq2VXpJQhdOqE9Asq/kkw+GS4c6AD9GdILmmQUH3Tn KZCiY2wzujE2j1VjOmCPHfn+7X8gYAG4OARlHBffEgorBgEEAZdVAQUBAQdAyvP3E1DykVzz 7VjVTT3JcAZOnV4tjH3Pnu+YwGJdylEDAQgHiHgEGBYIACoFgmUcF98JkMVb+z+YwtcIApsM FiEEI/DFvIjrAtkVxM55xVv7P5jC1wgAADU2AP4l7GE6+jTfSEoE1p/NRZ3Au5cWxRXSim70 Ka7nW9E4NAD9FuYgs7TCaiKkcu6pnRVaFkEYUC41LzbHjATtY0czBg4= Message-ID: <4e78b2d3-d04e-bbdf-51bb-5d52ec7c0cd2@systella.fr> Date: Sun, 12 Jan 2025 15:17:50 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0 SeaMonkey/2.53.20 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="RmkZqsQ46TrhepIwIZnRBB52bUUk8xNk2" X-Virus-Scanned: clamav-milter 1.4.1 at rayleigh X-Virus-Status: Clean X-Rspamd-Queue-Id: 4YWHYP6VGLz4hTn X-Spamd-Bar: ----- X-Spamd-Result: default: False [-5.16 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.994]; R_MIXED_CHARSET(0.83)[subject]; DMARC_POLICY_ALLOW(-0.50)[systella.fr,reject]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; R_DKIM_ALLOW(-0.20)[systella.fr:s=mail]; R_SPF_ALLOW(-0.20)[+a:rayleigh.systella.fr]; ONCE_RECEIVED(0.10)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_ALL(0.00)[]; HAS_ATTACHMENT(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; DKIM_TRACE(0.00)[systella.fr:+]; ASN(0.00)[asn:44407, ipnet:2a0a:1c80::/29, country:FR]; ARC_NA(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~] This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --RmkZqsQ46TrhepIwIZnRBB52bUUk8xNk2 Content-Type: multipart/mixed; boundary="cdWD1bJ0XEckGe5kHaPK5DYx7T2rkzNOo" --cdWD1bJ0XEckGe5kHaPK5DYx7T2rkzNOo Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello, I've just upgraded my FreeBSD 14.1 to 14.2 with freebsd-upgrade. Just after upgrade, I have done a pkg upgrade -f. System runs fine with X, but console is unusable. I can see first kernel message at boot. Kernel starts and when it tries to load graphic driver, screen remains black. For information, I have installed drm-61-kmod-6.1.92.1401000_3, drm-kmod-20220907_3 and gpu-firmware-kmod-20241114,1. System runs with and i7 (4770) and internal GPU (intel). I'm trying to fix this issue since yesterday without success. Help will be welcome. Best regards, JB --cdWD1bJ0XEckGe5kHaPK5DYx7T2rkzNOo-- --RmkZqsQ46TrhepIwIZnRBB52bUUk8xNk2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQQj8MW8iOsC2RXEznnFW/s/mMLXCAUCZ4PPDwAKCRDFW/s/mMLX CCtAAP9x+GzOzuREuVzG5/cELd51GvYueRYAfAhOe1ky0P710AEA/+9s18AhaQkN 2uJHBURxQI8oORWKPCucxaXv6R3lOAA= =ewz3 -----END PGP SIGNATURE----- --RmkZqsQ46TrhepIwIZnRBB52bUUk8xNk2-- From nobody Sun Jan 12 14:47:47 2025 X-Original-To: freebsd-hackers@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 4YWJCj6dQ3z5knHb for ; Sun, 12 Jan 2025 14:48:01 +0000 (UTC) (envelope-from yaroslaw.mashko@gmail.com) Received: from mail-pj1-x1036.google.com (mail-pj1-x1036.google.com [IPv6:2607:f8b0:4864:20::1036]) (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 4YWJCj4ggqz4knX for ; Sun, 12 Jan 2025 14:48:01 +0000 (UTC) (envelope-from yaroslaw.mashko@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pj1-x1036.google.com with SMTP id 98e67ed59e1d1-2eeb4d643a5so6156220a91.3 for ; Sun, 12 Jan 2025 06:48:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736693280; x=1737298080; 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=zOdG+fefDMBhkEb8i5gBC36DZFaWjj+3hfGMwNmAH5M=; b=Rk9TaQ5AVGrd+8EZCZsfQmcZq0k2rCQpt9iIpm+tgqNSbiB92uXgYHielnqc1KzCC8 +geeWqoKvSKe2QV4HwV3gIqAUW6KdQ22igqVfgJF4KgiQhWRJWR4HdaH2NOKR8xp+A8D xATRRWr3ZeUQ81W/WU0vM6X4EU8KzaSq11mojAcDwSkzOOT6RrlBxSLgSOdVwo78W6H4 ymLCO6ZH6i3x1JZTr+2TTTEfqLbcht6L9w91h4DL00zK4uWLPl9GTv3xEAXwG/0EJWnW A24ksPL6Soz3gu5+FZfdKyIq2UFT/RYectZ4WPVcBni5Fn2gL7h2iMK1zzKQsTG6DUac HQOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736693280; x=1737298080; 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=zOdG+fefDMBhkEb8i5gBC36DZFaWjj+3hfGMwNmAH5M=; b=h2NN20YlZvag0WdzAg6+hCkBVZeDzj0O8zVZCcAO5EeeMi+AnE4T7tyyR4h3+UT3/y CCAdEOkPRwoPbkDEdfzo0IhmhdARrsKaWixo0oc0FDLGBSZhFM0KPwB9Nd/DYSD5pvtE bcsp6WP8qyIbD6UX5E8DjomX7QStx3e+zBgZGi97xe1xK/U1p4OkfBJ6G/P+W31RQSCf yfYH4/DD3pzldGzPcw99QQgVhiAh5K2WT/ZwRXaZgDUIt8Gkb7qQRc/Ya84CGzIEqZwH 2L7H7+aCbHXR74/nHU9rJUY3R1pC+5zHfNPBdeZxOQpxhlrgxBwKSxIkpcJE5dfcJvk0 tCGw== X-Gm-Message-State: AOJu0YzRwPM65fKAD7M6fZoQper3ZNqxgdh0Ssor1AGk0SJ0rmPQsfo+ 50tHqBw19hxjQoEp80kKnDbo47GGtu5qsmEbUNG+bjEXhaQLWVAeYchW0Xga4zngbblAwzZVJI6 IYDqwR3ZsNJNkKhAzOy5o9KK4KwetzQ== X-Gm-Gg: ASbGncv5vLOqRaOO3OGG3CEG0E74PzAdIVinEJJ3X98T5SjoV2LEeZ2xVLf/Zblheb0 PStDoN2/7WIFryy05HALu3rnzqlxvGBbOK1sY X-Google-Smtp-Source: AGHT+IGw8NvXtDLZbBkVM/sl7Z0vNAoGNY634UpBLSO8UoDLO2PsacpwsDrBaFw3uWIzlIpY3UWUcnFsoDTKmVkaQEI= X-Received: by 2002:a17:90a:f94d:b0:2ea:696d:732f with SMTP id 98e67ed59e1d1-2f5490bd806mr25448331a91.29.1736693280110; Sun, 12 Jan 2025 06:48:00 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 References: <4e78b2d3-d04e-bbdf-51bb-5d52ec7c0cd2@systella.fr> In-Reply-To: <4e78b2d3-d04e-bbdf-51bb-5d52ec7c0cd2@systella.fr> From: =?UTF-8?B?0K/RgNC+0YHQu9Cw0LIg0JzQsNGI0LrQvg==?= Date: Sun, 12 Jan 2025 16:47:47 +0200 X-Gm-Features: AbW1kvamGkMmKjdSV4S-SloeBLAZ3Tg3B9zZfxpJMtPG88-w1OV3-4JMfSlq4GA Message-ID: Subject: Re: [14.2] No console To: =?UTF-8?Q?BERTRAND_Jo=C3=ABl?= Cc: Eduardo Morras via freebsd-hackers Content-Type: multipart/alternative; boundary="0000000000000b7d6f062b836a8e" X-Rspamd-Queue-Id: 4YWJCj4ggqz4knX X-Spamd-Bar: ---- 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:2607:f8b0::/32, country:US] --0000000000000b7d6f062b836a8e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello, I'd started a thread recently about an issue. X starts, but can not switch to other tty. My understanding of the situation is very vague. I think my X was catching up a wrong drm, or failing to start with it. It relyied on xorg intel drivers from the Xorg own repository. Somehow bulding drm-61-kmod from ports fixed the issue. Hope it helped, for more insight, I can not say anything. Something with a versioning system. Binary packages do not sync exactly to the release. Maybe someone will provide more input here. =D0=B2=D1=81, 12 =D1=8F=D0=BD=D0=B2. 2025 =D0=B3., 16:18 BERTRAND Jo=C3=ABl= : > Hello, > > I've just upgraded my FreeBSD 14.1 to 14.2 with freebsd-upgrade. > Just > after upgrade, I have done a pkg upgrade -f. > > System runs fine with X, but console is unusable. I can see first > kernel message at boot. Kernel starts and when it tries to load graphic > driver, screen remains black. > > For information, I have installed drm-61-kmod-6.1.92.1401000_3, > drm-kmod-20220907_3 and gpu-firmware-kmod-20241114,1. > > System runs with and i7 (4770) and internal GPU (intel). I'm > trying to > fix this issue since yesterday without success. Help will be welcome. > > Best regards, > > JB > > > --0000000000000b7d6f062b836a8e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hello,

I'd started a thread recently about an issue. X starts, = but can not switch to other tty.

My understanding of the situation is very vague. I think my = X was catching up a wrong drm, or failing to start with it. It relyied on x= org intel drivers from the Xorg own repository.

Somehow bulding drm-61-kmod from ports fixed the issue.

Hope it helped, for more insight, I can not say anything. So= mething with a versioning system. Binary packages do not sync exactly to th= e release. Maybe someone will provide more input here.


=D0=B2=D1=81, 12 =D1=8F=D0=BD=D0=B2. 2025 =D0=B3., 16:18 BE= RTRAND Jo=C3=ABl <joel.bert= rand@systella.fr>:
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 Hello,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 I've just upgraded my FreeBSD 14.1 to 14.2 = with freebsd-upgrade. Just
after upgrade, I have done a pkg upgrade -f.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 System runs fine with X, but console is unusabl= e. I can see first
kernel message at boot. Kernel starts and when it tries to load graphic
driver, screen remains black.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 For information, I have installed drm-61-kmod-6= .1.92.1401000_3,
drm-kmod-20220907_3 and gpu-firmware-kmod-20241114,1.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 System runs with and i7 (4770) and internal GPU= (intel). I'm trying to
fix this issue since yesterday without success. Help will be welcome.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Best regards,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 JB


--0000000000000b7d6f062b836a8e-- From nobody Sun Jan 12 15:27:37 2025 X-Original-To: freebsd-hackers@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 4YWK5V1Jb4z5kqmh for ; Sun, 12 Jan 2025 15:27:42 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qv1-xf2a.google.com (mail-qv1-xf2a.google.com [IPv6:2607:f8b0:4864:20::f2a]) (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 4YWK5T4gS5z4npc for ; Sun, 12 Jan 2025 15:27:41 +0000 (UTC) (envelope-from markjdb@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-qv1-xf2a.google.com with SMTP id 6a1803df08f44-6d8f916b40bso48692666d6.3 for ; Sun, 12 Jan 2025 07:27:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736695660; x=1737300460; darn=freebsd.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:from:to:cc:subject:date:message-id :reply-to; bh=lZ6o+i9dZkmBSN4nYzakLpJJG9+X2ztJFduu2OI91Ng=; b=M4BHt2OeS1P0HCihNCmyZhdrXYDErYfC/C7NohhjeZKjWHs3UsV4St6fvDoGxb45nr 5O7gDnaTiWk4/upRjjcG1PclAnp5yzKynZ0Omx0wQbImA2S3gQjdQPs6B6Mif8vDw7jk 8vXYBT1x5w0/Qwp2k4fGEi/VsJnD3zt7oY5mkO2j20P+kZu4d+TfX+5bComUJrTiOmVc ptlr8Q5ntvdCJ9DDpCx/yvQmjOfyw64rzERN3Si2Gt5jeF4OpjkRjqWBh0QwAN09cw/e NuHVDpKOBFfvrgeXfSrZ2VPdCbf8MiStt4+HbOfAg4b2DH/b2KhDYPLeEqcHfAI3QM+v dp4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736695660; x=1737300460; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=lZ6o+i9dZkmBSN4nYzakLpJJG9+X2ztJFduu2OI91Ng=; b=Lg0GOeKWIdduPuoB2wPzr942ziQ6yNoWNuOyxXX3qrZEH/7AWeo6RmdQYfGwVZz98x AI6u6rk3bmqS/4/wKepggsEBgISWUMjQBcJfNPFQbkdhitEqGdZfw46Rx2ZNMTPYh0R7 S0Ek5gaQcwZ4+OjWsFtE9yL1aBrpwZgUZumFrJQRHFYVlWLFv7sDcpIjZS/3ss5nco3x 97B/DCSoC0T0xFbgvLGHK0LRfVfYSPdAOKqSZ5m3H1iRrYBvIKhG0oqQjWWXQEB8Jb5F U7UeXD8+GfhAKR5eGHYMs4q+sJtvBhIjXRK1UazBQOq4c5fBpNQESMtHNW4j/5N7ZZVI 2nKg== X-Gm-Message-State: AOJu0YwQdTPFc6j2jCSSSRGjaNXyga2g0Gk7VWIDrMNKtaVcuReZH6Ix 33ufw18KGwyupPqiKzDnnZhBt3IMisgo+pMRaZDw/GdBX5B16Es2fChR5g== X-Gm-Gg: ASbGncunLqeZia2d7YBUJ3r3/HPywJ/TRw3dGLkjT9kuwc7GJeZeLQmRVSfOYRrjcxM lfGpbFQLCxTc9x1dZno9XhBSTo4DPM4RDqQWLvGTBsJn213Bn+1vCfMGARVVA6cXaxwxDAFNMNh NWAxJLlij38hUryrCofU+g0jB2M18jyzjKV/JU05/JXCSYbu0sHD42lEyIKCHgX/fv3i91Ge+Kc Hrb6htKyHESunIOMyquTRIJz4inH/7jcaELHmyS7m8H/eSibQXnD1PUVNEG97OX/ZuzlNE= X-Google-Smtp-Source: AGHT+IFK/Va1EPyDX4J2SbGKkPv9AqTx5zKzYb+0cQYOmf/O0Y9qpgawpjtU7H4Q0RNL9uMrG7JACg== X-Received: by 2002:a05:6214:1d24:b0:6d8:821d:736e with SMTP id 6a1803df08f44-6df9b28d3camr330262576d6.36.1736695660261; Sun, 12 Jan 2025 07:27:40 -0800 (PST) Received: from nuc (192-0-220-237.cpe.teksavvy.com. [192.0.220.237]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-6dfadeb40d4sm30890306d6.119.2025.01.12.07.27.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 12 Jan 2025 07:27:39 -0800 (PST) Date: Sun, 12 Jan 2025 10:27:37 -0500 From: Mark Johnston To: Tomoaki AOKI Cc: freebsd-hackers@freebsd.org Subject: Re: widening ticks Message-ID: References: <20250111131106.4d2657de20eeed7eef5c0b15@dec.sakura.ne.jp> <20250112043543.86b303419f954b2b287d39d1@dec.sakura.ne.jp> <20250112075038.4cd7fc680400e07a32a13f1a@dec.sakura.ne.jp> <20250112111651.e76aea0843ac8f85043c7f10@dec.sakura.ne.jp> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250112111651.e76aea0843ac8f85043c7f10@dec.sakura.ne.jp> X-Rspamd-Queue-Id: 4YWK5T4gS5z4npc X-Spamd-Bar: ---- 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] On Sun, Jan 12, 2025 at 11:16:51AM +0900, Tomoaki AOKI wrote: > Replying to ML only, as Mark's gmail address seems to block previous > one. > > On Sat, 11 Jan 2025 18:00:12 -0500 > Mark Johnston wrote: > > > On Sun, Jan 12, 2025 at 07:50:38AM +0900, Tomoaki AOKI wrote: > > > On Sat, 11 Jan 2025 17:35:36 -0500 > > > Mark Johnston wrote: > > > > > > > On Sun, Jan 12, 2025 at 04:35:43AM +0900, Tomoaki AOKI wrote: > > > > > Not an example of code, but for example, when ticksl is at > > > > > 0x7fffffffffffffff (positive value), ticks shoule be 0xffffffff > > > > > (negative value), if I read the diff correctly. > > > > > The same thing starts happening ticksl is at 0x0000000080000000 throug > > > > > 0x00000000ffffffff and values alike. So signs (carry bits, usually the > > > > > leftmost bit of each) should be checked separately for ticksl and ticks. > > > > > > > > That's true, but I can't see why any code would care about this? > > > > > > While ticks is defined as (signed) int, it shoule be turnaround when it > > > reaches at 0x7fffffff (as incrementing it causes overflow). > > > Is ticks allowed to be minus value? My guess is that it is monotonic > > > counter. > > > > Yes, INT_MAX ticks elapse in approximately 25 days at 1000Hz. In fact, > > ticks is initialized to INT_MAX - in subr_param.c so that > > it wraps around shortly after boot, after which it is negative. > > > > Kernel code should not care about the sign of ticks. > > Thanks! I've overlooked it. > > BTW, does tickl restricted with INT_MAX, too? (In detail, although tickl > has the type long, but actually the range of the values used are > restricted with INT_MAX?) No, that's the point of the change: the kernel now increments a counter of type long, so it will eventually reach LONG_MAX. Existing code which references ticks will still get a 32-bit value that behaves the same as before. From nobody Sun Jan 12 15:49:45 2025 X-Original-To: freebsd-hackers@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 4YWKbC1sN3z5krqS for ; Sun, 12 Jan 2025 15:49:59 +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 4YWKbB0Xv5z4r4Q for ; Sun, 12 Jan 2025 15:49:58 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=ZGxeYwu+; 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; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-ed1-x52a.google.com with SMTP id 4fb4d7f45d1cf-5d3bdccba49so6020515a12.1 for ; Sun, 12 Jan 2025 07:49:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736696997; x=1737301797; 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=hrpVEwfqDBxuFZL59JJlM28+zSUR/Berg4qdm/7Iz5w=; b=ZGxeYwu+OsiJtPU1Y6QCxSfWC6xsc3etc5LzaqGI6XEb22rueA2srt9SrDBSrYyJYY PwJVqPWVSAtt7uLM1Mg1NvhLMWOMZwf5wHQhB7KFQgCKnIBsH6BSBYy8j+vOJrLHUbZd 1aRhfJKeUpIXcdFL829ER7CAd/UonfDorvEneXvt6KgA5dTDqq6W5y4/eWobIjxKx6Wp fCeM/1Nk2cCbJT4fJah4SCPPB2d8YKxWA7VnuWI1u+a3CAWVE/pGurzwBKz4S9uGNLhb BUvnpjZFshtCMhCnJo+h+Jn6AVPSpLlh9EO5FuymUu20RaD0Clb0id3oVsOBptAiZs/+ EsAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736696997; x=1737301797; 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=hrpVEwfqDBxuFZL59JJlM28+zSUR/Berg4qdm/7Iz5w=; b=VNwhnso30KFFtwQ+XCDn8tw38N83ZcBomYZEzINgOS6+piamn03TKDYE5OXoJOuE3L mWARjmlmXBwhfZGZulTX68GCsYupn9/IB1KZ7oR2UqOg3k1oyFqiCUB9TNB+vj32BDu5 F8tOoI1Z15yOm3wODvJUPNQBRth7hp3QL+EhhSy+0R/HpJNklx5ihAc68TOt3skg05kH uACTqqOacnWtNejvDOivmyjqA6VGI+UDkkaUXLUmM489ElZ//n/spL2dANYb0pWvdq76 KEwjE9Pc/hQhdNqi4iK1FWCpZpjUC8cgci3w2xu/muDPb+Vyd3TSa8uBw/Qy5cD2qCum A/9g== X-Gm-Message-State: AOJu0YztRl+Uu+ohyG45nUr0QiDJlVv0vh3IcLwkq6kw2EeEb89rVKBj XDAhZoBUm1OYJpmGhmy7wJZ1TsV+oA/yB5SUTtbzAOx7FrAbtbuxS4Fo9vjFeqGfQFwJAbVkGgj mm0ZNR6N03MD8bkkX6zVo8VEWrA== X-Gm-Gg: ASbGncvmoNSHayJxcpSLEwIDxG17BZeBnM5tbX+3YcRh0ihzRRCVbdb687tiIQAXqyn Ijdi6ZkdK+JjSd/qeQVkt4Y+zOzBqs7uMVMlHRdS5Y9UCKymL89WtwXJxXnmCnGz5zO2IY1c= X-Google-Smtp-Source: AGHT+IF0hMlHuwvhb9YFoa56+pqrRGX73KLmpdWYurUo739QJUlQI/8cwpp0/OkrdzzJobII8e3sGDU3QmnHZaDjxBw= X-Received: by 2002:a05:6402:2345:b0:5d0:b51c:8479 with SMTP id 4fb4d7f45d1cf-5d972e0a087mr17042089a12.10.1736696996443; Sun, 12 Jan 2025 07:49:56 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 References: In-Reply-To: From: Rick Macklem Date: Sun, 12 Jan 2025 07:49:45 -0800 X-Gm-Features: AbW1kvZA_uQPaLtI-V3UijAb2D4cSTDQV4vnKgPfm7wpbasdU3UIEE1fcfDg-Y0 Message-ID: Subject: Re: FreeBSD NFSv4.1 nfsd, named attribute support (OPENATTR)? To: Cedric Blancher Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4YWKbB0Xv5z4r4Q X-Spamd-Bar: -- X-Spamd-Result: default: False [-3.00 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; 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]; FREEMAIL_TO(0.00)[gmail.com]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; TAGGED_FROM(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; MISSING_XM_UA(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; MLMMJ_DEST(0.00)[freebsd-hackers@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]; TAGGED_RCPT(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::52a:from] On Sun, Jan 12, 2025 at 2:09=E2=80=AFAM Cedric Blancher wrote: > > Good morning! > > Does FreeBSD NFSv4.1 nfsd support named attributes (e.g. OPENATTR), > per https://datatracker.ietf.org/doc/html/rfc5661#section-5.3 > > ZFS and Solaris UFS support named attributes (via O_XATTR), does > FreeBSD do it too? No. fork files/resource forks (or whatever you choose to call them) have been discussed multiple times. If I recall correctly, one showstopper was fixing the archive tools. There was also the generic argument that Linux doesn't support them. Then there was the issue of what VFS/VOP changes were required. (The FreeBSD VFS carries vnode locks across VOP calls and is at what I would call a lower level than Solaris.) --> Which all comes down to who will do the work? If I recall correctly, there was a time when a group associated with CERN needed them to transition away from Solaris. Anyhow, maybe the discussion will happen again here and now, rick > > Ced > -- > Cedric Blancher > [https://plus.google.com/u/0/+CedricBlancher/] > Institute Pasteur > From nobody Sun Jan 12 16:20:39 2025 X-Original-To: freebsd-hackers@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 4YWLGs6jbgz5ktnt for ; Sun, 12 Jan 2025 16:20:53 +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 4YWLGq3HV0z4tTy for ; Sun, 12 Jan 2025 16:20:51 +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=XjAFvGOK; 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; dmarc=pass (policy=none) header.from=dec.sakura.ne.jp Received: from kalamity.joker.local (124-18-43-234.area1a.commufa.jp [124.18.43.234]) (authenticated bits=0) by www121.sakura.ne.jp (8.17.1/8.17.1/[SAKURA-WEB]/20201212) with ESMTPA id 50CGKexB048652 for ; Mon, 13 Jan 2025 01:20:40 +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=1736698840; bh=4GoTmhvVNG0hgXnrPMsjb+zNFj5z+UHwxBdrca6YNOc=; h=Date:From:To:Subject:In-Reply-To:References; b=XjAFvGOKewoV75JPiWq9UsVyuA0PTdRMuqNXc/6hDFLfOe/rgxfeDMa/Zl3zTOObE 6w3D6ovToO1+v6pUzp46OSoJ//JjnD+EsS6qgV0lTz9iNmCOOrRW0MwLFLQiqgvrhY p7X+2ZPV3a0PjNInW+Ofyop9GyUN2jyI8aP1ih/o= Date: Mon, 13 Jan 2025 01:20:39 +0900 From: Tomoaki AOKI To: freebsd-hackers@freebsd.org Subject: Re: widening ticks Message-Id: <20250113012039.d476e10859c00f7b55f78280@dec.sakura.ne.jp> In-Reply-To: References: <20250111131106.4d2657de20eeed7eef5c0b15@dec.sakura.ne.jp> <20250112043543.86b303419f954b2b287d39d1@dec.sakura.ne.jp> <20250112075038.4cd7fc680400e07a32a13f1a@dec.sakura.ne.jp> <20250112111651.e76aea0843ac8f85043c7f10@dec.sakura.ne.jp> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.2) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4YWLGq3HV0z4tTy X-Spamd-Bar: ++ X-Spamd-Result: default: False [2.21 / 15.00]; URIBL_RED(3.50)[dec.sakura.ne.jp:dkim]; SUSPICIOUS_URL_IN_SUSPICIOUS_MESSAGE(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.989]; MV_CASE(0.50)[]; HAS_ANON_DOMAIN(0.10)[]; BAD_REP_POLICIES(0.10)[]; MIME_GOOD(-0.10)[text/plain]; ONCE_RECEIVED(0.10)[]; DMARC_POLICY_ALLOW(0.00)[dec.sakura.ne.jp,none]; DKIM_TRACE(0.00)[dec.sakura.ne.jp:+]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; GREYLIST(0.00)[pass,meta]; R_DKIM_ALLOW(0.00)[dec.sakura.ne.jp:s=s2405]; HAS_ORG_HEADER(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_SPF_ALLOW(0.00)[+ip4:153.125.133.16/28]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP]; ARC_NA(0.00)[] On Sun, 12 Jan 2025 10:27:37 -0500 Mark Johnston wrote: > On Sun, Jan 12, 2025 at 11:16:51AM +0900, Tomoaki AOKI wrote: > > Replying to ML only, as Mark's gmail address seems to block previous > > one. > > > > On Sat, 11 Jan 2025 18:00:12 -0500 > > Mark Johnston wrote: > > > > > On Sun, Jan 12, 2025 at 07:50:38AM +0900, Tomoaki AOKI wrote: > > > > On Sat, 11 Jan 2025 17:35:36 -0500 > > > > Mark Johnston wrote: > > > > > > > > > On Sun, Jan 12, 2025 at 04:35:43AM +0900, Tomoaki AOKI wrote: > > > > > > Not an example of code, but for example, when ticksl is at > > > > > > 0x7fffffffffffffff (positive value), ticks shoule be 0xffffffff > > > > > > (negative value), if I read the diff correctly. > > > > > > The same thing starts happening ticksl is at 0x0000000080000000 throug > > > > > > 0x00000000ffffffff and values alike. So signs (carry bits, usually the > > > > > > leftmost bit of each) should be checked separately for ticksl and ticks. > > > > > > > > > > That's true, but I can't see why any code would care about this? > > > > > > > > While ticks is defined as (signed) int, it shoule be turnaround when it > > > > reaches at 0x7fffffff (as incrementing it causes overflow). > > > > Is ticks allowed to be minus value? My guess is that it is monotonic > > > > counter. > > > > > > Yes, INT_MAX ticks elapse in approximately 25 days at 1000Hz. In fact, > > > ticks is initialized to INT_MAX - in subr_param.c so that > > > it wraps around shortly after boot, after which it is negative. > > > > > > Kernel code should not care about the sign of ticks. > > > > Thanks! I've overlooked it. > > > > BTW, does tickl restricted with INT_MAX, too? (In detail, although tickl > > has the type long, but actually the range of the values used are > > restricted with INT_MAX?) > > No, that's the point of the change: the kernel now increments a counter > of type long, so it will eventually reach LONG_MAX. Existing code which > references ticks will still get a 32-bit value that behaves the same as > before. Thanks. Will read related codes more deeper to understand once I can take long enough time. -- Tomoaki AOKI From nobody Sun Jan 12 16:58:00 2025 X-Original-To: freebsd-hackers@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 4YWM6C1Kpdz5kxdk for ; Sun, 12 Jan 2025 16:58:27 +0000 (UTC) (envelope-from freebsd@ny-central.org) Received: from mail2.ny-central.com (mail2.ny-central.com [173.212.246.2]) by mx1.freebsd.org (Postfix) with ESMTP id 4YWM6B0kxdz40F4 for ; Sun, 12 Jan 2025 16:58:26 +0000 (UTC) (envelope-from freebsd@ny-central.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=ny-central.org header.s=202405 header.b=oRqMlDZS; spf=pass (mx1.freebsd.org: domain of freebsd@ny-central.org designates 173.212.246.2 as permitted sender) smtp.mailfrom=freebsd@ny-central.org; dmarc=pass (policy=none) header.from=ny-central.org X-Virus-Scanned: amavisd-new at ny-central.com DKIM-Filter: OpenDKIM Filter v2.10.3 mail2.ny-central.com D78971AF6DB DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ny-central.org; s=202405; t=1736701099; bh=YvdP8R1kdIdIifFQKt3EjceJaqdt08LDmF9uw8kWShc=; h=Date:From:To:cc:Subject:In-Reply-To:References; z=Date:=20Sun,=2012=20Jan=202025=2017:58:00=20+0100=20(CET)|From:=2 0Chris=20Moerz=20|To:=20=3D?KOI8-R?B?8dLP0 8zB1yDtwdvLzw=3D=3D?=3D=20|cc:=20=3D?IS O-8859-15?Q?BERTRAND_Jo=3DEBl?=3D=20,=2 0=0D=0A=20=20=20=20Eduardo=20Morras=20via=20freebsd-hackers=20|Subject:=20Re:=20[14.2]=20No=20console|I n-Reply-To:=20|References:=20<4e78b2d3-d04e-bbdf-51bb-5d52ec7c0c d2@systella.fr>=20; b=oRqMlDZSVIFQAroc6ykXP5LfnzojM6ODxR7RRgNi/UHD257G9JuT0qK/mx+/EIl1G dq0TxN4qTvTcU0hoFP4ongMMFg2b3CzbOve/dgnrV3Hqas2vdi2rfYis6mnTerRTCp BB2RfaYa6uH/M9NkMHFoBIkUvtigHEjQTuH+yTxH0jHDTrF0KDM3ZJd3FoS5q/K0/J AF48JAhtisUXWGq73cx+wOTg+gz62fYs64KI6vAn90sSoG8DprKFKbjC6uiUbj0GQK fi3PAmAUpl0+cWkURzXjoDQZfn1wHs/Uqe5CBHoeztOlhJjQK3NYAToIvuiPpxgQE3 j2X+Dy0LI/Jtc9LBBfU1ExIze7vdjJkJgHgWr4mX7AKH3XaZr/Eiw/YzUiPe2JNKdV GiDxhm0Og1EVzXRm2NDO8qaxjVwd2VP9rQsperqFPHNlywgy9Inrywnqws3gBOUGkS zmQnO25lPlk462nJa8SI9VQ8U4FoibkQOJSeWRxTdeUMt2FjLSWH+xkId9a8eZ6SuW K/u+s/PYWUF6Wpl3b0zDaNzprge/8ARLXqFRbWROcKrTD1D8mjjJFa3pwsNzZsAZ0U AqwB/28uT/9tBynE1F4DbjO1Y9MvyeGM1GeTLqEG/hTExFuqlozSFKUhL26wrmUD7z imHm9XLMeS/fES3XPz6KipS8= Received: from tenforward.ny-central.local (unknown [192.168.11.104]) by mail2.ny-central.com (Postfix) with ESMTPSA id D78971AF6DB; Sun, 12 Jan 2025 17:58:08 +0100 (CET) Date: Sun, 12 Jan 2025 17:58:00 +0100 (CET) From: Chris Moerz To: =?KOI8-R?B?8dLP08zB1yDtwdvLzw==?= cc: =?ISO-8859-15?Q?BERTRAND_Jo=EBl?= , Eduardo Morras via freebsd-hackers Subject: Re: [14.2] No console In-Reply-To: Message-ID: <9afc3bbd-e20c-21db-45bc-a5e032c3f0b9@ny-central.org> References: <4e78b2d3-d04e-bbdf-51bb-5d52ec7c0cd2@systella.fr> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="3328038562-1395444126-1736701088=:86494" X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=4.0.1 X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on mail2.ny-central.com X-Rspamd-Queue-Id: 4YWM6B0kxdz40F4 X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.90 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; CTYPE_MIXED_BOGUS(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[ny-central.org,none]; R_SPF_ALLOW(-0.20)[+a]; R_DKIM_ALLOW(-0.20)[ny-central.org:s=202405]; MIME_GOOD(-0.10)[multipart/mixed,text/plain]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:51167, ipnet:173.212.240.0/21, country:DE]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+]; RCVD_VIA_SMTP_AUTH(0.00)[]; MISSING_XM_UA(0.00)[]; TAGGED_RCPT(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; TO_DN_ALL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FREEMAIL_TO(0.00)[gmail.com]; DKIM_TRACE(0.00)[ny-central.org:+] This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --3328038562-1395444126-1736701088=:86494 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT On Sun, 12 Jan 2025, Ярослав Машко wrote: > > Somehow bulding drm-61-kmod from ports fixed the issue. > That's exactly it - you will need to build graphics/drm-61-kmod directly from ports. Clone the ports repo into /usr/ports, i.e. run as root: $ cd /usr/ports $ git clone https://github.com/freebsd/freebsd-ports /usr/ports $ cd graphics/drm-61-kmod $ make -j${NCPU} $ make reinstall replace ${NCPU} with number of cores of your system. Right now, the binary packages do not line up properly with minor releases; there is work underway to improve this, but it's not there yet. You will have to redo this potentially every time you do a release upgrade, until the fix is in place. Let me know if you have any further questions. chris --3328038562-1395444126-1736701088=:86494-- From nobody Sun Jan 12 19:44:46 2025 X-Original-To: freebsd-hackers@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 4YWQpY2MzRz5l9Nq for ; Sun, 12 Jan 2025 19:45:09 +0000 (UTC) (envelope-from joel.bertrand@systella.fr) Received: from rayleigh.systella.fr (rayleigh.systella.fr [IPv6:2a0a:1c84:1000:a00::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "*.systella.fr", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4YWQpX0Yw1z4P6X for ; Sun, 12 Jan 2025 19:45:07 +0000 (UTC) (envelope-from joel.bertrand@systella.fr) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=systella.fr header.s=mail header.b=nQ4ODCDO; spf=pass (mx1.freebsd.org: domain of joel.bertrand@systella.fr designates 2a0a:1c84:1000:a00::2 as permitted sender) smtp.mailfrom=joel.bertrand@systella.fr; dmarc=pass (policy=reject) header.from=systella.fr DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=systella.fr; s=mail; t=1736711094; bh=S7bZgFLqU7c8DjyBPVz/Xq8hUMFDBfH4uY+2g6LnIfs=; h=Subject:To:References:From:Date:In-Reply-To:From; b=nQ4ODCDOPh4yG06t4LQETEVROIIRB0yyoigtKJXaEvvRpq8HqanvGd4JK6E/1ktUX kQVvgYrK5eRYM/Us/eZT06Ib0urZKkkPgsmCv0iGLBnZ6gb/ZnfHoAT0SIakTUVOFv oUg0b6YM/3iQdjB6pTnGljxAorwQLAezE9eRNMAqpeHywI6TNiUmJHRIyJ4IPuGwLk wURzDUnHTWlljcORDWoAEH0oFMBaZc5RIsnPaVTYkRIsPbGAQXE6hCPpexIe+WrLnM t8U2Ua3m0+fWKJzCg3lKEJFuz/q2QDpvPDwA2jm5FOMjR3xNGjneVXCsU6SoODfDjq WY/tGtBH4q3Rg== Received: from [192.168.10.103] (hilbert.systella.fr [192.168.10.103]) (authenticated bits=0) by rayleigh.systella.fr (8.18.1/8.18.1/Debian-6) with ESMTPSA id 50CJiq7t017440 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Sun, 12 Jan 2025 20:44:54 +0100 Subject: Re: [14.2] No console To: freebsd-hackers@freebsd.org References: <4e78b2d3-d04e-bbdf-51bb-5d52ec7c0cd2@systella.fr> <9afc3bbd-e20c-21db-45bc-a5e032c3f0b9@ny-central.org> From: =?UTF-8?Q?BERTRAND_Jo=c3=abl?= Autocrypt: addr=joel.bertrand@systella.fr; prefer-encrypt=mutual; keydata= mDMEZRwX3xYJKwYBBAHaRw8BAQdAPnfO4wC5CMbkYaOioVYbTVmx5dnKJwvYZ8EKDFyZGyO0 KkJFUlRSQU5EIEpvw6tsIDxqb2VsLmJlcnRyYW5kQHN5c3RlbGxhLmZyPoiMBBAWCgA+BYJl HBffBAsJBwgJkMVb+z+YwtcIAxUICgQWAAIBAhkBApsDAh4BFiEEI/DFvIjrAtkVxM55xVv7 P5jC1wgAADaKAQCkdx4kqKvHPhJGYGrq2VXpJQhdOqE9Asq/kkw+GS4c6AD9GdILmmQUH3Tn KZCiY2wzujE2j1VjOmCPHfn+7X8gYAG4OARlHBffEgorBgEEAZdVAQUBAQdAyvP3E1DykVzz 7VjVTT3JcAZOnV4tjH3Pnu+YwGJdylEDAQgHiHgEGBYIACoFgmUcF98JkMVb+z+YwtcIApsM FiEEI/DFvIjrAtkVxM55xVv7P5jC1wgAADU2AP4l7GE6+jTfSEoE1p/NRZ3Au5cWxRXSim70 Ka7nW9E4NAD9FuYgs7TCaiKkcu6pnRVaFkEYUC41LzbHjATtY0czBg4= Message-ID: <0b3cf931-4e82-1732-1186-3d14414d4c7a@systella.fr> Date: Sun, 12 Jan 2025 20:44:46 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0 SeaMonkey/2.53.20 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 In-Reply-To: <9afc3bbd-e20c-21db-45bc-a5e032c3f0b9@ny-central.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="UgcB9yigWLz92Tfdffn2TS8fZFMR9xsp7" X-Virus-Scanned: clamav-milter 1.4.1 at rayleigh X-Virus-Status: Clean X-Rspamd-Queue-Id: 4YWQpX0Yw1z4P6X X-Spamd-Bar: ----- X-Spamd-Result: default: False [-5.29 / 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)[-1.000]; R_MIXED_CHARSET(0.71)[subject]; DMARC_POLICY_ALLOW(-0.50)[systella.fr,reject]; R_SPF_ALLOW(-0.20)[+a:rayleigh.systella.fr]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; R_DKIM_ALLOW(-0.20)[systella.fr:s=mail]; ONCE_RECEIVED(0.10)[]; DKIM_TRACE(0.00)[systella.fr:+]; HAS_ATTACHMENT(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:44407, ipnet:2a0a:1c80::/29, country:FR]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~] This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --UgcB9yigWLz92Tfdffn2TS8fZFMR9xsp7 Content-Type: multipart/mixed; boundary="x5wAhAz00LWGvT9WbXCuNptTflZb9L6ze" --x5wAhAz00LWGvT9WbXCuNptTflZb9L6ze Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Chris Moerz a =C3=A9crit=C2=A0: > On Sun, 12 Jan 2025, =D0=AF=D1=80=D0=BE=D1=81=D0=BB=D0=B0=D0=B2 =D0=9C=D0= =B0=D1=88=D0=BA=D0=BE wrote: >=20 >> >> Somehow bulding drm-61-kmod from ports fixed the issue. >> >=20 > That's exactly it - you will need to build graphics/drm-61-kmod directl= y > from ports. Clone the ports repo into /usr/ports, i.e. run as root: >=20 > $ cd /usr/ports > $ git clone https://github.com/freebsd/freebsd-ports /usr/ports > $ cd graphics/drm-61-kmod > $ make -j${NCPU} > $ make reinstall >=20 > replace ${NCPU} with number of cores of your system. >=20 > Right now, the binary packages do not line up properly with minor > releases; there is work underway to improve this, but it's not there ye= t. >=20 > You will have to redo this potentially every time you do a release > upgrade, until the fix is in place. >=20 > Let me know if you have any further questions. > chris OK. I will try to do a portsnap auto and rebuild package from sources. Thanks, JB --x5wAhAz00LWGvT9WbXCuNptTflZb9L6ze-- --UgcB9yigWLz92Tfdffn2TS8fZFMR9xsp7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQQj8MW8iOsC2RXEznnFW/s/mMLXCAUCZ4QbrgAKCRDFW/s/mMLX CDzIAQDVTaYG9tcm+fczsAkJPNyXI6MqkCcAOM/1pc4qzPy3YgD+Pdp7rZmEpyzu SVbeituXg7xVDXFflFLD6kYGLA1F/AI= =Li+S -----END PGP SIGNATURE----- --UgcB9yigWLz92Tfdffn2TS8fZFMR9xsp7-- From nobody Sun Jan 12 21:17:51 2025 X-Original-To: freebsd-hackers@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 4YWSsn6Xkpz5jqZh for ; Sun, 12 Jan 2025 21:18:05 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-ej1-f43.google.com (mail-ej1-f43.google.com [209.85.218.43]) (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 4YWSsm6vfsz4Z6y for ; Sun, 12 Jan 2025 21:18:04 +0000 (UTC) (envelope-from asomers@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.218.43 as permitted sender) smtp.mailfrom=asomers@gmail.com; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=freebsd.org (policy=none) Received: by mail-ej1-f43.google.com with SMTP id a640c23a62f3a-aaecf50578eso728000266b.2 for ; Sun, 12 Jan 2025 13:18:04 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736716683; x=1737321483; 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=jCyTK2Ksr3Ac5G1vMuPh61XTf2vq7MA3ET6lqNvlNLI=; b=Nu7OE7cJ3UmIiTcr/i5IZIWaQACdIm28lDELdo3dkV5qS6gqEt9s16utSwbVRXHG1x VrxadgER9HdZlIgOgNN1WmWSZ/LRkDLryQBNi5KzKXzZIygcCxWuw5fzG1K6EBLHOhs2 Bmg0vmXnSngsfSur2VzEl1UfFTC3Ett91qJODEylxi7vnM+xl1zD9GVO510mYeNcB2IS KhPCW0pxUsezcqcsJkmXJWCp7h5oy1ErI1LJvRHNpVkRmxE1f+YTNAhCC01CG7lgkcRL jyKuGnEcRUIHfo2zhA9QdGppyXVkKOrm3s4BQKbTJkbVrgqRjrLhA/cbkS73uKg25fnO NKow== X-Gm-Message-State: AOJu0Yw5srWuxPZXAHu1dD/waxn92ZkDr9NLaWpS4RypbptMndL0kOPD mDgBvfJpbIswND6/B8getpUtciqJzJQaxPeZxRcwvun0VDxKe3TAZwi4PZGczD+gk/H8JF5Nofq JEDWylNuKCHRNX+2CrIvylNeZkq0Hlw== X-Gm-Gg: ASbGnctzPxfPR29CoFJuTJvPXSPJx7v31LeaeL23Jx35BLpwoVHpV/s204QoMNfE9z+ k33LWFpStJCtQFfkmSHKSP7MF8vRHT8gKsPB0hQ== X-Google-Smtp-Source: AGHT+IFZy5A7DljZCEWuzp4v6XfxtjzE7gLjTRBzb+3LBXJTHTYwjDgLjZ2IkoVx8IQ2bKb8VN/MHa0S5Zrm+/v+nrA= X-Received: by 2002:a17:907:72d6:b0:aa6:88c6:9449 with SMTP id a640c23a62f3a-ab2ab56abc5mr1857465866b.19.1736716682744; Sun, 12 Jan 2025 13:18:02 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 References: In-Reply-To: From: Alan Somers Date: Sun, 12 Jan 2025 14:17:51 -0700 X-Gm-Features: AbW1kvYIamTYQyiwxUD0cfLCDBul2RZakbB_vqvQW8Ivg2QDuB--h4-MUfMuxWo Message-ID: Subject: Re: WRITE_SAME support in FreeBSD nfsd NFSv4.1 mode? To: Cedric Blancher Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4YWSsm6vfsz4Z6y X-Spamd-Bar: - X-Spamd-Result: default: False [-1.08 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-0.67)[-0.673]; NEURAL_HAM_SHORT(-0.51)[-0.509]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : SPF not aligned (relaxed), No valid DKIM,none]; MIME_GOOD(-0.10)[text/plain]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_TO(0.00)[gmail.com]; TO_DN_SOME(0.00)[]; MISSING_XM_UA(0.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FREEFALL_USER(0.00)[asomers]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.218.43:from]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; TAGGED_RCPT(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[209.85.218.43:from] On Sun, Jan 12, 2025 at 12:23=E2=80=AFAM Cedric Blancher wrote: > > On Fri, 10 Jan 2025 at 16:02, Alan Somers wrote: > > > > On Thu, Jan 9, 2025 at 5:31=E2=80=AFPM Dan Shelton wrote: > > > > > > Hello! > > > > > > Does FreeBSD nfsd support the WRITE_SAME request in NFSv4.1 mode? > > > > > > Dan > > > -- > > > Dan Shelton - Cluster Specialist Win/Lin/Bsd > > > > Out of curiosity, what is your use case? > > As discussed in the linux-nfs@ list, is a typical "big data" and > database accelerator, for example fast pattern fill (1 WRITE_SAME > command over the write, compared to commands with data block, > where is typically > 200 average), or just zero fill for blocks. > It's basically reducing network traffic dramatically. > > Windows SMB 3.0 already supports that, and is a main selling point for > M$ to keep database people on the W$ platform. They even added several > Windows syscalls like > https://learn.microsoft.com/en-us/windows/win32/api/winioctl/ni-winioctl-= fsctl_set_zero_data > > Ced I understand why WRITE SAME would greatly reduce network traffic compared to writing the same data n times. But my question is, what real application requires that, where the data isn't simply all-zeros? Are there database operations that require writing the same non-zero pattern to multiple blocks?