From nobody Tue Dec 17 19:27:38 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 4YCRfR4hjyz5hcSg for ; Tue, 17 Dec 2024 19:27:43 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (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 4YCRfR2Rd7z4TCr; Tue, 17 Dec 2024 19:27:43 +0000 (UTC) (envelope-from markjdb@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-qt1-x82b.google.com with SMTP id d75a77b69052e-4679eacf25cso29237881cf.3; Tue, 17 Dec 2024 11:27:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1734463662; x=1735068462; 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=sikpmuVhMi5uEr9cN8LuPeQp/azzNyWCVtD5nK80410=; b=N4D96A4GQuiwokX0TLYDugb0M+vbaiht+9h/v7aO1gxbXlINHMASyeeUUssFp1NISD hE5yD4XXRGjRfh4ubfVdRWu/fuIIVPBLNvxMoNH+dPy++h0ht6odORTpzcfuzDSqQZ6b Y/3gSWawY4Gx1WGC+xvdPE44RZ2jomMmuE11+cySC1WE4YvqQFxXdMi9ePd7DYVv83I3 ajy3oO23wnHaJ2RMn2GlRzkJHC0NnCaxQ2iNIsEEf5AMsoTl3Vc0z4AHYGtE31Ywy7Z7 tVUOI55VCWE2P0k03uQIJd4MV2Ud7VzNwx4UdUgWW9D1ISHkvzvEsv7TiA1ZG3RGKF0C k8ow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734463662; x=1735068462; 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=sikpmuVhMi5uEr9cN8LuPeQp/azzNyWCVtD5nK80410=; b=GBs2AnFVLRMTuh6QPrYuBYN92ZUVcjeXcIk0inuDrUz5KxmTOPMh4OiQeORal7jGn/ 46RcfOGhB4MQW5eyvIuOkaDvk7dyrz6xoMVjW49YPKBPnR/O6O+jlIgP0u/kN13DDmbb ryv0/KBsxEXKGQlV1xmtqJG6/X2oAIItKt2hnraE8WhPK+HAwvLtL4CkB75kd09LVhb2 P/l3WEqXcfRThEdASL/bht8nKDfpa0IHFTpblsJ/HMwLWezfhd1XNJgnZBiY/3yURHOP PMfb7mtGKtsUy7EEihToEqSMcNBl/XMIahcTr7Eiaz1KfinDCd+GEf7JhAyqDATLgHCP kWOQ== X-Gm-Message-State: AOJu0YwPcvthQM24jzb3B87/ZIm+YjFBiB7Vrmjq/8WdVdbNmFeL+j+y TVp95UrhGee/BmuUaYezdEMCLEWxegKKbk9hAgFgHLhUjaYleffvDwg57A== X-Gm-Gg: ASbGncvgdufrzuaBfIrCnoXkpmI1VsRqZaVL/kIRioQaEmcdaa3qep7aKK3BcB2cPK6 mjzgpeY8eojLBFhIyoyvJaqqNTgWgPaax67zxJ4i1zvT4cBjFDM0IklfZ6+Cj+LhUEiqSMQmT8i uXocBsEUb9WVWm+tia96z2U2JapsgTmVbNfswKErAjYFhHmCYlwPZYSg+1X0HPUNkchNoFRkYAq FBBU1/EmakTuVr7paOvIUj7St62o8AID62/sIeCEeCTl4/lmDAIBFAzr3xL9Ba0GYIemXM= X-Google-Smtp-Source: AGHT+IFMYWyjDjtn7FKq94qzv50ONTMQLDsCJAJ+SfEqfGdTYxYMhrsHB3NPo/FpSjWGLO5bBSGpwQ== X-Received: by 2002:ac8:5a48:0:b0:467:65d4:7e07 with SMTP id d75a77b69052e-46908ec9ab6mr247441cf.53.1734463662116; Tue, 17 Dec 2024 11:27:42 -0800 (PST) Received: from nuc (192-0-220-237.cpe.teksavvy.com. [192.0.220.237]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-467b2cbb69asm42657471cf.39.2024.12.17.11.27.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Dec 2024 11:27:41 -0800 (PST) Date: Tue, 17 Dec 2024 14:27:38 -0500 From: Mark Johnston To: Alan Somers Cc: FreeBSD CURRENT Subject: Re: Why does namei return an exclusively locked vnode when LOCKSHARED is specified? Message-ID: References: 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 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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] X-Rspamd-Queue-Id: 4YCRfR2Rd7z4TCr X-Spamd-Bar: ---- 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==$target/ > {printf("islocked=%#x", args[0]->a_vp->v_vnlock->lk_lock); stack();}' > -i 'fbt:kernel:vop_stdstat:entry /pid==$target/ > {printf("islocked=%#x", args[0]->a_vp->v_vnlock->lk_lock);}' -c > "./getattr --gtest_filter=Getattr.attr_cache -v" > [==========] Running 1 test from 1 test suite. > [----------] Global test environment set-up. > [----------] 1 test from Getattr > [ RUN ] Getattr.attr_cache > INIT ino= 0 > ACCESS ino= 1 mask=0x1 > LOOKUP ino= 1 some_file.txt > GETATTR ino=42 > [ OK ] Getattr.attr_cache (3 ms) > [----------] 1 test from Getattr (3 ms total) > > [----------] Global test environment tear-down > [==========] 1 test from 1 test suite ran. (4 ms total) > [ PASSED ] 1 test. > CPU ID FUNCTION:NAME > 3 19743 vop_stdstat:entry islocked=0x21 > 3 19743 vop_stdstat:entry islocked=0xfffff80004f16740 > 3 68298 fuse_vnop_getattr:entry islocked=0xfffff80004f16740 > 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=0xfffff80004f16740 > 3 68298 fuse_vnop_getattr:entry islocked=0xfffff80004f16740 > 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?