From nobody Tue Dec 17 20:02:18 2024 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4YCSQd388hz5hfWd for ; Tue, 17 Dec 2024 20:02:33 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-ed1-f52.google.com (mail-ed1-f52.google.com [209.85.208.52]) (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 4YCSQc6q08z4Xg5; Tue, 17 Dec 2024 20:02:32 +0000 (UTC) (envelope-from asomers@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-f52.google.com with SMTP id 4fb4d7f45d1cf-5d3e6f6cf69so2621425a12.1; Tue, 17 Dec 2024 12:02:32 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734465751; x=1735070551; 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=HSvS9hikQgHwQ0/+gc+R/5zsN4hIyPWkLRkxA3QrurY=; b=PcQIL2hWG2mGdTW6/HD+aZxVXCKvIpaGHiFUs0Kf2nMAAFtca3wh/XOUT4eYRRSjVJ TLptRqvmZUOEfqQevVJ28wh2lo3/hDav8Q2Tw6mvwHomeCTYIu9uRas1Jry4QanNbQK7 v/+XeV0WSlJO5Wi0r06+jwtZxYSSlgxCLxpjqiS8kqldMAsMAz+I4e5FIGdoCxIiMO+3 8p102ACONBapGqevZEoOdyWn4qLkwmmn3HG+nLKf58+aWE3Nb8jakT67chaLOCNjSp3a 4MI6uHLMvmnEQjN0WyiQfNWm1t5nzdZpWuLijnUkM9q1ObT/jcXLaSZ6fTRE9CWiiwpX BFxA== X-Gm-Message-State: AOJu0YzcVGXxVtBm0pgkhmDfnDQJZPI4xVMCVu91PVre31ggZxNeY5t4 Yq8OGRQ0n/MyKPecFHKljzDN9uVdMwEuzkICMuGOqR4midDOfqE2Pi9MUQPQFA+pSFa4TgrKu7B 5KVmGosa2LmOGkyVlFfwKgQWLUNN2VQ== X-Gm-Gg: ASbGncuZjJ7PER5IrJgu2PakCH5yA8mrQg9m8iph3yaV0mUOL19LVbrCJKp0B7Fn/w5 igtkyn3ABe37CDKVtVt26qJOo3bL6yXk4KBvoeA== X-Google-Smtp-Source: AGHT+IF7A6nCZAp7bijcUvYUqNFdp7d22tKhyZKzxGhyXRNjvpxFB/fuTuddHeqXWc7R5p1TZqPlgv4htxJ/1o3+KCk= X-Received: by 2002:a05:6402:448a:b0:5d0:a80d:bce9 with SMTP id 4fb4d7f45d1cf-5d7ee3b62c0mr250840a12.20.1734465750636; Tue, 17 Dec 2024 12:02:30 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 References: In-Reply-To: From: Alan Somers Date: Tue, 17 Dec 2024 13:02:18 -0700 Message-ID: Subject: Re: Why does namei return an exclusively locked vnode when LOCKSHARED is specified? To: Mark Johnston Cc: FreeBSD CURRENT Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US] X-Rspamd-Queue-Id: 4YCSQc6q08z4Xg5 X-Spamd-Bar: ---- On Tue, Dec 17, 2024 at 12:27=E2=80=AFPM Mark Johnston = wrote: > > On Tue, Dec 17, 2024 at 12:19:26PM -0700, Alan Somers wrote: > > According to namei(9), namei should return a shared lock when > > LOCKSHARED is specified. But in my experiments, it always seems to > > return an exclusive lock instead. For example: > > > > $ cd /usr/tests/sys/fs/fusefs > > $ sudo dtrace -i 'fbt:fusefs:fuse_vnop_getattr:entry /pid=3D=3D$target/ > > {printf("islocked=3D%#x", args[0]->a_vp->v_vnlock->lk_lock); stack();}' > > -i 'fbt:kernel:vop_stdstat:entry /pid=3D=3D$target/ > > {printf("islocked=3D%#x", args[0]->a_vp->v_vnlock->lk_lock);}' -c > > "./getattr --gtest_filter=3DGetattr.attr_cache -v" > > [=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D] Running 1 test from 1 test suite. > > [----------] Global test environment set-up. > > [----------] 1 test from Getattr > > [ RUN ] Getattr.attr_cache > > INIT ino=3D 0 > > ACCESS ino=3D 1 mask=3D0x1 > > LOOKUP ino=3D 1 some_file.txt > > GETATTR ino=3D42 > > [ OK ] Getattr.attr_cache (3 ms) > > [----------] 1 test from Getattr (3 ms total) > > > > [----------] Global test environment tear-down > > [=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D] 1 test from 1 test suite ran. (4 ms to= tal) > > [ PASSED ] 1 test. > > CPU ID FUNCTION:NAME > > 3 19743 vop_stdstat:entry islocked=3D0x21 > > 3 19743 vop_stdstat:entry islocked=3D0xfffff80004f167= 40 > > 3 68298 fuse_vnop_getattr:entry islocked=3D0xfffff80004f167= 40 > > kernel`VOP_GETATTR_APV+0x90 > > kernel`vop_stdstat+0x147 > > kernel`VOP_STAT_APV+0x91 > > kernel`kern_statat+0x183 > > kernel`sys_fstatat+0x27 > > kernel`amd64_syscall+0x1af > > kernel`0xffffffff8106cd5b > > > > 3 19743 vop_stdstat:entry islocked=3D0xfffff80004f167= 40 > > 3 68298 fuse_vnop_getattr:entry islocked=3D0xfffff80004f167= 40 > > kernel`VOP_GETATTR_APV+0x90 > > kernel`vop_stdstat+0x147 > > kernel`VOP_STAT_APV+0x91 > > kernel`kern_statat+0x183 > > kernel`sys_fstatat+0x27 > > kernel`amd64_syscall+0x1af > > kernel`0xffffffff8106cd5b > > > > dtrace: pid 3554 has exited > > > > From that output, the first vop_stdstat is probably for the > > mountpoint, and isn't what I'm concerned about. But the second two > > are for a fusefs file. The LK_SHARE bit is not set, indicating an > > exclusive lock. That's even though the call to namei in kern_statat > > specifies LOCKSHARED | LOCKLEAF. > > > > What am I missing? > > Having noticed the same phenomenon in p9fs and scratching my head for a > while: is fusefs failing to call VN_LOCK_ASHARE() in this case? I see > that it's predicated on "data->dataflags & FSESS_ASYNC_READ", but I'm > not sure why - the comment seems to suggest a misunderstanding of what > VN_LOCK_ASHARE() does. > > ... oh, also perhaps because fusefs mounts don't set MNTK_LOOKUP_SHARED? Yes, that's it! Both of those things need to change. Now I can get on with solving my real bug. Thank you.