Date: Wed, 18 Dec 2024 11:15:45 -0700 From: Alan Somers <asomers@freebsd.org> Cc: Mark Johnston <markj@freebsd.org>, FreeBSD CURRENT <freebsd-current@freebsd.org> Subject: Re: Why does namei return an exclusively locked vnode when LOCKSHARED is specified? Message-ID: <CAOtMX2gBaFwHF=1Xo8MSv4Q6w8ReeGZDxXBBVjYMSDF8Nu=2SA@mail.gmail.com> In-Reply-To: <CAOtMX2jgPjtHhA7PaX_qidnJkZ034uzrKLKFKZfq%2BjryauQ5sw@mail.gmail.com> References: <CAOtMX2hKxcE8ZWeEvQn58xGdD9H1wLsHoeQXfjEvkF4WACVYfA@mail.gmail.com> <Z2HQqu06_XxFEpWI@nuc> <CAOtMX2jgPjtHhA7PaX_qidnJkZ034uzrKLKFKZfq%2BjryauQ5sw@mail.gmail.com>
index | next in thread | previous in thread | raw e-mail
On Tue, Dec 17, 2024 at 1:02 PM Alan Somers <asomers@freebsd.org> wrote:
>
> On Tue, Dec 17, 2024 at 12:27 PM Mark Johnston <markj@freebsd.org> 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==$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?
>
> Yes, that's it! Both of those things need to change. Now I can get
> on with solving my real bug. Thank you.
FYI: this is the bug I was working on:
https://github.com/freebsd/freebsd-src/pull/1556
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOtMX2gBaFwHF=1Xo8MSv4Q6w8ReeGZDxXBBVjYMSDF8Nu=2SA>