From nobody Mon Sep 22 08:54:27 2025 X-Original-To: dev-commits-src-main@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 4cVcPM6Sg0z68pmC for ; Mon, 22 Sep 2025 08:54:47 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cVcPM3DvNz3wX8 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-x629.google.com with SMTP id a640c23a62f3a-b2e0513433bso48918066b.1 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=KnQh5/wv1acrgLsUO7avU8PTxX8nldftwjXwVQpynaLcki4bv1abEUxW9Wa4tIazzv 28m3HUgqbzvggh7PPstoGU/3NaM+l3u/DY8IkBBosWP0nnp+WcGhbZk23bJ8E54gibFb 8C8iCa2pIKStCRpdZvaBK9ZDjk0lHnw/pg03L8cc8kB9MiaHLvlN/jNteNKUEfbN7zpP P+r7Xu6wF4ddcfdOnOft5rIq6cmbq1kSDwYLZriFAvSoKJJ3ddeiDH4p8dDzRN4LxBCu L7efCaDSpQx7m0IUAvNRPUwzjulZ0evVzAYLAzFk/P+cpdKK6Dy9a+9uKvFUwrliyTt7 zFFA== X-Forwarded-Encrypted: i=1; AJvYcCWNuw0eD7kbxA6iLCVvnXV4BObcnToUEBAoioInXFUqxbRK7htpL5jh/PUpBXlZwYNIZ4GcwNlasYurnJe1jQdfld5DLA==@freebsd.org X-Gm-Message-State: AOJu0YxiITD5ONO3HAwkyGjNPDHFPlqkoWN24GTONp+85iGZwSneQf+b kR/57MrHi4bgiotuM8IyxR0spDmEJobGF2++tBarBKvCxCGZcLVDjFvjVcDAgkx6P3493udjGLu PU0XiGLEzM9wvkIAaKoG3++tf9/VvVJ4= X-Gm-Gg: ASbGnctQzwdwcvOQIVRGsZ+CLy/ykLOfBB+IB4jikRVzpabZbL5K/pLljzLXAyR21rh TNXP7DWCB+7Q8OjNdW7kiMbFjSYAEe6R90HHl2mu0g4eyZHewYEsVlolQchfGsQP0q8ALCI48G+ 3peZHYQN7z24vMMHF2aNbaRFSnWneLe/QYiJSz8V8om/e5p8vXFROnSNYneyGQRT2MPywGAxHJw lqQrxFkP/XdcRm9eCbuSXNt26At8XYsUDR0ZYC2DgngDrrm 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 the main branch of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-main List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: dev-commits-src-main@freebsd.org Sender: owner-dev-commits-src-main@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: 4cVcPM3DvNz3wX8 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.