From nobody Mon Sep 22 08:54:27 2025 X-Original-To: dev-commits-src-all@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 4cVcPM6T3pz68q9Z for ; Mon, 22 Sep 2025 08:54:47 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) (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 4cVcPM3CjMz3wZh for ; Mon, 22 Sep 2025 08:54:47 +0000 (UTC) (envelope-from mjguzik@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ej1-x62f.google.com with SMTP id a640c23a62f3a-b07d4d24d09so692073766b.2 for ; Mon, 22 Sep 2025 01:54:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1758531280; x=1759136080; 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=p4nsIok/texjVZyDKIwsui8pDc4nNAsb0gGNGIaqlh8=; b=meKx8M8ZEC4xWIol7R8Enj3E5DQ5C4zMNZ73317/mTp8W7g29PiaLHtYcPZfjvdbVj wGGAFQcsYyFfO39eiQ6fr3ex9s29dy2LZV74SUm/N+6R25CJNoJX6nbHS+o3ObDRZDTx +G4lX1tuL7+35GFyxcMr5tLuIcL+P31LCHgmvuRgjBwZi1fJlyvC3ZwcH8aduk6XBnTe sV3XB7E4mok6tfkwOkMJSBhTIiwjWrxyNuZ5oqXJNKlE7lXjv62gsjqRlbmrJkLsaEz+ hS9anEWWJ63uevLhOlgR7QbQUSH6u2kxpqdTJvndeJ05YEwBPWDip2ZC/48iCVcxuJeW lvGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1758531280; x=1759136080; 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=p4nsIok/texjVZyDKIwsui8pDc4nNAsb0gGNGIaqlh8=; b=On0vL8rn1eRTh8UJkxIiNnkboTfTKZO/DoIs5eWcZ9FNNgGZ+zH5oAVAWzm6CBB807 Esz5GjDLp7ywPcAwy0ap6XkAX8/+Zf8jnk5AMfm9LMfCTlS6zCMXvjspFnAeHI60bCHI y/GbqwSNkBb/YY9sXzBNikW/Fb9DvQwuxrLTVs5smkB8Wck8WyCfgEy7fMHONldei9Mi 6/i3nGyz9LR67iuHiSN40I9kmzB9WNp3PUPCJB8sh/NxCp5W5C5RbosFgqe2+OUoFAip /jbdj22O90cJEvHXWR3TkABNmVDF2/cZRzGLmN/EtmKz2h95SsLoSEETGTFMR4KvJwfa zx3g== X-Forwarded-Encrypted: i=1; AJvYcCXHYZ2O1uWZfKqv6EDPAx9NuK1hW8Y18iUVAGImZqNyRFcruN9uSy7zYU0gRnnJcaofzdSjLNPiQ7MQ0u8QrpLykBu+@freebsd.org X-Gm-Message-State: AOJu0Ywh2mTnIkufANE9mqGXwJ9W7iX6pE6WHgaSUGwWfnQTpWItEJwp HBwVXQQ3cTZSz/tTIIoNigpsBpyr9krY6SNcut2gT5iq2G6yb1zMMvLxBXLNpicZKCMP9eXoNtP tW6Uge8rd2QMevHGUOdx8EXT7raMD/0E= X-Gm-Gg: ASbGnct4RQ9GaGBPTm0464aLVhIFqkicrWjNW4owq6rSkQnyDA91X+Lf6g+r/CBceig 4jmGpDqSEoN1DPv3hETNvq0G2K5itUr7uDSg0oHnv4DATuYhPH945e90WfLwuPouOi50NDYU2Wi lwAVpRjYxAReGDlLiPfol02n+ZaYfJnbiFKbt1Q91az/KocmqdlG4Bf/r/mK4cHEKeZWTofroLP ebZu/uczw7BbjeAH7cjTayyXSF+kIsnvODDmrYNP7ZYahyY X-Google-Smtp-Source: AGHT+IGs2Kba6uislMugWdzsWyTUqJ93MfB3LJAQULBZ+2udlswtI9alNwimutwRWRj4y8IElxMhZ4e4XnJRyD0UTeY= X-Received: by 2002:a17:907:72c1:b0:b04:83af:b4ba with SMTP id a640c23a62f3a-b24f4cd16bcmr1202389366b.52.1758531279883; Mon, 22 Sep 2025 01:54:39 -0700 (PDT) List-Id: Commit messages for all branches of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: dev-commits-src-all@freebsd.org Sender: owner-dev-commits-src-all@FreeBSD.org MIME-Version: 1.0 References: <202509191419.58JEJsvj031867@gitrepo.freebsd.org> <92831372-745d-4612-b38f-aeb235dd8cca@FreeBSD.org> In-Reply-To: <92831372-745d-4612-b38f-aeb235dd8cca@FreeBSD.org> From: Mateusz Guzik Date: Mon, 22 Sep 2025 10:54:27 +0200 X-Gm-Features: AS18NWDT-zTybmcw0u8g7EEeFoKJ50Ou-apfiGoJofwNxZo54cmOA95LTKwwVd4 Message-ID: Subject: Re: git: 40a42785dbba - main - fcntl(F_SETFL): only allow one thread to perform F_SETFL To: John Baldwin Cc: Konstantin Belousov , src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4cVcPM3CjMz3wZh On Mon, Sep 22, 2025 at 10:41=E2=80=AFAM John Baldwin wro= te: > > On 9/19/25 10:19, Konstantin Belousov wrote: > > The branch main has been updated by kib: > > > > URL: https://cgit.FreeBSD.org/src/commit/?id=3D40a42785dbba93cc5196178f= c49d340c1a89cabe > > > > commit 40a42785dbba93cc5196178fc49d340c1a89cabe > > Author: Konstantin Belousov > > AuthorDate: 2025-09-11 10:05:04 +0000 > > Commit: Konstantin Belousov > > CommitDate: 2025-09-19 14:19:13 +0000 > > > > fcntl(F_SETFL): only allow one thread to perform F_SETFL > > > > Use f_vflags file locking for this. > > Allowing more than one thread handling F_SETFL might cause de-sync > > between real driver state and flags. > > > > Reviewed by: markj > > Tested by: pho > > Sponsored by: The FreeBSD Foundation > > MFC after: 2 weeks > > Differential revision: https://reviews.freebsd.org/D52487 > > Thanks for fixing this. I still slightly worry that "home-grown" locks > aren't visible to WITNESS and it's checking. > Another problem with these is that they don't do adaptive spinning. In particular for file offset, it *is* putting threads off cpu in real workloads when it plausibly could be avoided. I think the real thing to do here is to drop the hand-rolled machinery and use an sx lock. Currently struct file is 80 bytes which is a very nasty size from caching standpoint. Locks are 32 bytes in size, which is another problem, but ultimately one can be added here without growing the struct past 128 bytes. The only issue here is that files are marked as NOFREE, so this memory can *never* be reclaimed. One could be tempted to use smr here, but the cost of smr_enter is prohibitive. There is a lazy variant which does not do atomics, which perhaps could work, but that 0 users in the tree and was probably never tested. With 32-bit archs going away I don't think it's a big deal though. For interested, on Linux the struct is 256 bytes.