Date: Tue, 24 Sep 2024 17:53:57 +0000 From: John F Carr <jfc@mit.edu> To: J David <j.david.lists@gmail.com> Cc: Rick Macklem <rick.macklem@gmail.com>, FreeBSD FS <freebsd-fs@freebsd.org> Subject: Re: panic: nfsv4root ref cnt cpuid = 1 Message-ID: <AF09244D-85AF-41EE-B540-C9149D68AA3C@mit.edu> In-Reply-To: <CABXB=RTPE4xwE7nCAOoQS_GufL%2BX7UwN%2BiA9vaP7JjDafRTESg@mail.gmail.com> References: <CABXB=RShoxwT3PuPQK9OdJNBbWrShUuYchK7oVnT7gBbLH5D0w@mail.gmail.com> <CABXB=RRKvfiwipfaaNA%2BAuA3Ug1VLyNvxa_o-5hWEq1-qjjTbg@mail.gmail.com> <CAM5tNy5Hh=6b9ZNseeQsRddLSFehiTsYNZOH==CeAGthie5SQw@mail.gmail.com> <CABXB=RRDG6-_NU1rjrmT86Hv7uDRzSAbj-HP5ryd1WQ6ZUZNTA@mail.gmail.com> <CABXB=RQZ4jjWe39Nd26u66ZQURjvybL5eCeGX=n%2Bk3EaJRdfZQ@mail.gmail.com> <CAM5tNy6L7C6f1rN2%2BkUaC_TdfMQkTfCS38BqE=RU60E9VExgww@mail.gmail.com> <CABXB=RTPE4xwE7nCAOoQS_GufL%2BX7UwN%2BiA9vaP7JjDafRTESg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Sep 24, 2024, at 13:32, J David <j.david.lists@gmail.com> wrote:
>
> On Mon, Sep 23, 2024 at 6:38 PM Rick Macklem <rick.macklem@gmail.com> wrote:
>> If you can easily get the source line# for nfsrpc_lookup+0x87f, that
>> could be helpful.
>
> Sure. I did it via lldb and got nfs_clrpcops.c 1697. Your method gives
> the same result.
>
> According to the github version of 14.1-RELEASE, that's the "if (ndp
> != NULL) {" after the call to nfscl_openrelease().
>
> Per lldb, the actual instruction at that address is:
>
> testq %r13, %r13
>
> My knowledge of amd64 assembler is nearly nil, but I *think* this
> corresponds to checking if ndp is null. And I think that %r13 is a
> register, so I'm not sure that could cause a page fault. Maybe the
> trace indicates that that's the line it would have come back to if
> something in nfscl_openrelease() hadn't gone wrong?
>
> Thanks!
>
The stack dump on the console tends to omit the frame that faulted.
The fault was probably in nfscl_openrelease or something it called.
The faulting instruction address 0xffffffff809da260 should be accurate.
The faulting data address 0x28 corresponds to the offset of field
nfsow_rwlock in struct nfsclowner. Perhaps in nfscl_openrelease
the expression op->nfo_own is NULL and the fault is in one of the
two function calls in this code block around line 850 of nfs_clstate.c.
owp = op->nfso_own;
if (NFSHASONEOPENOWN(nmp))
nfsv4_relref(&owp->nfsow_rwlock);
else
nfscl_lockunlock(&owp->nfsow_rwlock);
John Carr
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AF09244D-85AF-41EE-B540-C9149D68AA3C>