From nobody Thu Sep 22 10:11:26 2022 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 4MY9zj3Xwmz4cyVr; Thu, 22 Sep 2022 10:11:29 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-oi1-x231.google.com (mail-oi1-x231.google.com [IPv6:2607:f8b0:4864:20::231]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MY9zh3mVVz3mx7; Thu, 22 Sep 2022 10:11:28 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mail-oi1-x231.google.com with SMTP id n83so11667103oif.11; Thu, 22 Sep 2022 03:11:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:from:to:cc:subject:date; bh=uEbQVJrpoAucl1qDegxUUZbC1B8IcdtzSSA7Dl+KPgA=; b=pwXohf1IIfB32slg9sJwSmIVmE1dNvkah5IA/oWKDYRazOCoFiOqI5Ov/5hHpjz7iP BBbz+mdyevcMCY1R/X3YDt3tgxXd3pKi+iLnPYbh5OGc50lowy06J86vq3RbaxHZfzN7 coYcoJ7bUZDm27Sj5bZIFvcTDA6hmSACI72oaAQsGA0+9uxGrdCp1FN0wIEr53K2xSPV JrrbbwbAUUlQ097cbTeWI1loDNYONkB7yQyLO6e2tTY+YpkPjLK5sA99jL4i7PgIXFmP c7sGOwEw1tjHthbvMTKUcvAd0G2LvnfzSnNdyfT2N2/fl/MnvBfXTrGF7bqLxM3MI8jJ 8tBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=uEbQVJrpoAucl1qDegxUUZbC1B8IcdtzSSA7Dl+KPgA=; b=RLkC/u5croNdSLPcmnKYwIWOyRB7RcPi7gRzm+Vj4x5bV0xR7S4VmwNN7yeMrsX3zr GjX+Jz4np4B9Irws+0BjCHMTYzEbVXWhPh8gtmhzyDaf1qkP6dGWlOjhIVzc8Co30QC6 BlUzNIGSgHv5Ct5Ak850p71yKLFucCbOe5/VN7i/l2CV6W88L7nqTZS4t1l4ss1/adLt j+IeZRaTNBhIF48Y7hPNAKgABoCX2NmQc7Wnvn7J4bxXT1OE21SOdFiPAQqbeJjfkmny jG0Ef9CQ2cPB58AZVGWcZY7fcxcr7tGLtMFvqOQPGJvNCCUdFWlTIjg7XTsdhwN7OezL q44g== X-Gm-Message-State: ACrzQf0h7Wss1dE2liGAaqO+ktOLsDlQE0Y8ouvl56cttjPkhL5dqQUN 3ZnOUXteJqpEPi6xAERh+V7CWUz9OOzMIWs2YAZEfR0G X-Google-Smtp-Source: AMsMyM4y7mU4MkUv5WjI6Q9FP1qUHb8oOKiB+XNOALCizPDx00lFu+3ePlfWpaN0tH1O3xmRCEet59nfbyRYcHcwlOw= X-Received: by 2002:a05:6808:2390:b0:350:5c6b:5ef9 with SMTP id bp16-20020a056808239000b003505c6b5ef9mr1203281oib.96.1663841487552; Thu, 22 Sep 2022 03:11:27 -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: Sender: owner-dev-commits-src-all@freebsd.org X-BeenThere: dev-commits-src-all@freebsd.org MIME-Version: 1.0 Received: by 2002:a8a:352:0:b0:474:267f:5338 with HTTP; Thu, 22 Sep 2022 03:11:26 -0700 (PDT) In-Reply-To: References: <202209192009.28JK924f075123@gitrepo.freebsd.org> From: Mateusz Guzik Date: Thu, 22 Sep 2022 12:11:26 +0200 Message-ID: Subject: Re: git: 2c2ef670a79b - main - pseudofs: use the vget_prep/vget_finish idiom To: Benjamin Kaduk Cc: src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4MY9zh3mVVz3mx7 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=pwXohf1I; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of mjguzik@gmail.com designates 2607:f8b0:4864:20::231 as permitted sender) smtp.mailfrom=mjguzik@gmail.com X-Spamd-Result: default: False [-2.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.997]; NEURAL_HAM_LONG(-0.55)[-0.553]; NEURAL_SPAM_SHORT(0.55)[0.546]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::231:from]; FREEMAIL_TO(0.00)[gmail.com]; MLMMJ_DEST(0.00)[dev-commits-src-all@freebsd.org,dev-commits-src-main@freebsd.org]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N On 9/19/22, Benjamin Kaduk wrote: > On Mon, Sep 19, 2022 at 1:09 PM Mateusz Guzik wrote: > >> The branch main has been updated by mjg: >> >> URL: >> https://cgit.FreeBSD.org/src/commit/?id=2c2ef670a79b7f8fa84796a04885a3f76c914762 >> >> commit 2c2ef670a79b7f8fa84796a04885a3f76c914762 >> Author: Mateusz Guzik >> AuthorDate: 2022-09-19 20:07:10 +0000 >> Commit: Mateusz Guzik >> CommitDate: 2022-09-19 20:08:40 +0000 >> >> pseudofs: use the vget_prep/vget_finish idiom >> >> > > Picking an arbitrary commit to reply to: could you please add a bit more > detail about the "why" to commit messages in the future? > Having looked a little bit, it seems that this would be "as part of the > broader effort to remove the vnode interlock [from a specific class of > operations?]". A pointer to a bigger-picture doc would be great as well. The idiom at hand is over 3 years old now and employing it at this point should not require a justification. One can easily see not taking the interlock is faster both single- and multi-threaded, which makes the change worthwhile regardless of support for the flag in locking primitives going away or not. So happens I'm going to keep the flag support in vget itself for the time being. > I co-maintain an out-of-tree filesystem and commit messages like this make > it really hard for me to get a handle on whether I need to do anything and, > if so, where to start looking to find out what to do. An overall project > page would be a great reference, or even comment around the implementations > that points to a key differential revision that implemented the core > behavior. One of the things that's been really nice about developing for > the FreeBSD VFS in the past is how easy it is to determine what a > filesystem implementation needs to provide, and I'd love to see us continue > that tradition. > I'm definitely confused by this comment. VFS has rampant layering violations, including wtfs like filesystems sneaking in their own changes to cn_flags by literally or-ing into it mid-lookup (recently fixed, see 5b5b7e2ca2fa9a2418dd51749f4ef6f881ae7179) or leaking their internals out and consequently imposing completely unnecessary restrictions on the layer (see a comment above vput_final for an example). That said, the changes I normally made are either backwards-compatible or are guaranteed to blow up at compilation time (or worst case at runtime with an assert). I agree some form a general doc would be nice, but between spending time writing one or actually getting things done, I chose the latter. There are several filesystems which I have no intent in modifying beyond bare minimum to keep them operational, thus general theme of backwards compat will continue. -- Mateusz Guzik