I can give it a shot on one of my clients.
> On 15 Jan 2024, at 16:04, Rick Macklem <rick.mack...@gmail.com> wrote:
>
> On Mon, Jan 15, 2024 at 2:53 AM Peter Blok <pb...@bsd4all.org
> <mailto:pb...@bsd4all.org>> wrote:
>>
>> Hi,
>>
>> Forgot to mention I’m on 13-stable. The fix that is causing the crash with
>> automounted NFS is:
>>
>> commit cc5cda1dbaa907ce52074f47264cc45b5a7d6c8b
>> Author: Konstantin Belousov <k...@freebsd.org>
>> Date: Tue Jan 2 00:22:44 2024 +0200
>>
>> nfsclient: limit situations when we do unlocked read-ahead by nfsiod
>>
>> (cherry picked from commit 70dc6b2ce314a0f32755005ad02802fca7ed186e)
>>
>> When I remove the fix, the problem is gone. Add it back and the crash
>> happens.
> Kostik has already come up with a probable fix. If you want it right
> away, here it is,
> but he'll probably commit it soon anyhow:
> diff --git a/sys/fs/nfsclient/nfs_clbio.c b/sys/fs/nfsclient/nfs_clbio.c
> index c027d7d7c3fd..1cf45bb0c924 100644
> --- a/sys/fs/nfsclient/nfs_clbio.c
> +++ b/sys/fs/nfsclient/nfs_clbio.c
> @@ -414,6 +414,18 @@ nfs_bioread_check_cons(struct vnode *vp, struct
> thread *td, struct ucred *cred)
> return (error);
> }
>
> +static bool
> +ncl_bioread_dora(struct vnode *vp)
> +{
> + vm_object_t obj;
> +
> + obj = vp->v_object;
> + if (obj == NULL)
> + return (true);
> + return (!vm_object_mightbedirty(vp->v_object) &&
> + vp->v_object->un_pager.vnp.writemappings == 0);
> +}
> +
> /*
> * Vnode op for read using bio
> */
> @@ -486,9 +498,7 @@ ncl_bioread(struct vnode *vp, struct uio *uio, int
> ioflag, struct ucred *cred)
> * unlocked read by nfsiod could obliterate changes
> * done by userspace.
> */
> - if (nmp->nm_readahead > 0 &&
> - !vm_object_mightbedirty(vp->v_object) &&
> - vp->v_object->un_pager.vnp.writemappings == 0) {
> + if (nmp->nm_readahead > 0 && ncl_bioread_dora(vp)) {
> for (nra = 0; nra < nmp->nm_readahead && nra < seqcount &&
> (off_t)(lbn + 1 + nra) * biosize < nsize; nra++) {
> rabn = lbn + 1 + nra;
> @@ -675,9 +685,7 @@ ncl_bioread(struct vnode *vp, struct uio *uio, int
> ioflag, struct ucred *cred)
> * directory offset cookie of the next block.)
> */
> NFSLOCKNODE(np);
> - if (nmp->nm_readahead > 0 &&
> - !vm_object_mightbedirty(vp->v_object) &&
> - vp->v_object->un_pager.vnp.writemappings == 0 &&
> + if (nmp->nm_readahead > 0 && ncl_bioread_dora(vp) &&
> (bp->b_flags & B_INVAL) == 0 &&
> (np->n_direofoffset == 0 ||
> (lbn + 1) * NFS_DIRBLKSIZ < np->n_direofoffset) &&
>
> rick
> ps: It appears that autofs causes the directory to be read before it
> is open'd for
> some reason. I've never looked at autofs.
>
>>
>> Peter
>>
>> On 15 Jan 2024, at 09:31, Peter Blok <pb...@bsd4all.org> wrote:
>>
>> Hi,
>>
>> I do have a crash on a NFS client with stable of today
>> (4c4633fdffbe8e4b6d328c2bc9bb3edacc9ab50a). It is also autofs related. Maybe
>> it is the same problem.
>>
>> I have ports automounted on /am/ports. When I do cd /am/ports/sys and type
>> tab to autocomplete it crashes with the below stack trace. If I plainly
>> mount ports on /usr/ports and do the same everything works. I am using NFSv3
>>
>> Peter
>>
>>
>>
>>
>> Fatal trap 12: page fault while in kernel mode
>> cpuid = 2; apic id = 04
>> fault virtual address = 0x89
>> fault code = supervisor read data, page not present
>> instruction pointer = 0x20:0xffffffff809645d4
>> stack pointer = 0x28:0xfffffe00acadb830
>> frame pointer = 0x28:0xfffffe00acadb830
>> code segment = base 0x0, limit 0xfffff, type 0x1b
>> = DPL 0, pres 1, long 1, def32 0, gran 1
>> processor eflags = interrupt enabled, resume, IOPL = 0
>> current process = 6869 (csh)
>> trap number = 12
>> panic: page fault
>> cpuid = 2
>> time = 1705306940
>> KDB: stack backtrace:
>> #0 0xffffffff806232f5 at kdb_backtrace+0x65
>> #1 0xffffffff805d7a02 at vpanic+0x152
>> #2 0xffffffff805d78a3 at panic+0x43
>> #3 0xffffffff809d58ad at trap_fatal+0x38d
>> #4 0xffffffff809d58ff at trap_pfault+0x4f
>> #5 0xffffffff809af048 at calltrap+0x8
>> #6 0xffffffff804c7a7e at ncl_bioread+0xb7e
>> #7 0xffffffff804b9d90 at nfs_readdir+0x1f0
>> #8 0xffffffff8069c61a at vop_sigdefer+0x2a
>> #9 0xffffffff809f8ae0 at VOP_READDIR_APV+0x20
>> #10 0xffffffff81ce75de at autofs_readdir+0x2ce
>> #11 0xffffffff809f8ae0 at VOP_READDIR_APV+0x20
>> #12 0xffffffff806c3002 at kern_getdirentries+0x222
>> #13 0xffffffff806c33a9 at sys_getdirentries+0x29
>> #14 0xffffffff809d6180 at amd64_syscall+0x110
>> #15 0xffffffff809af95b at fast_syscall_common+0xf8
>>
>>
>>
>> On 15 Jan 2024, at 06:46, FreeBSD User <free...@walstatt-de.de> wrote:
>>
>> Am Sun, 14 Jan 2024 20:34:12 -0800
>> Cy Schubert <cy.schub...@cschubert.com> schrieb:
>>
>> In message <CAM5tNy5aat8vUn2fsX9jV=D9yGZdnO20Q0Ea7qtszx+zSES2bw@mail.gmail.c
>> om>
>> , Rick Macklem writes:
>>
>> On Sat, Jan 13, 2024 at 12:39=E2=80=AFPM Ronald Klop <ronald-li...@klop.ws>=
>> wrote:
>>
>>
>>
>> Van: FreeBSD User <free...@walstatt-de.de>
>> Datum: 13 januari 2024 19:34
>> Aan: FreeBSD CURRENT <freebsd-current@freebsd.org>
>> Onderwerp: NFSv4 crash of CURRENT
>>
>> Hello,
>>
>> running CURRENT client (FreeBSD 15.0-CURRENT #4 main-n267556-69748e62e82a=
>>
>> : Sat Jan 13 18:08:32
>>
>> CET 2024 amd64). One NFSv4 server is same OS revision as the mentioned cl=
>>
>> ient, other is FreeBSD
>>
>> 13.2-RELEASE-p8. Both offer NFSv4 filesystems, non-kerberized.
>>
>> I can crash the client reproducable by accessing the one or other NFSv4 F=
>>
>> S (a simple ls -la).
>>
>> The NFSv4 FS is backed by ZFS (if this matters). I do not have physicla a=
>>
>> ccess to the client
>>
>> host, luckily the box recovers.
>>
>> Did you rebuild both the nfscommon and nfscl modules from the same sources?
>> I did a commit to main that changes the interface between these two
>> modules and did bump the
>> __FreeBSD_version to 1500010, which should cause both to be rebuilt.
>> (If you have "options NFSCL" in your kernel config, both should have
>> been rebuilt as a part of
>> the kernel build.)
>>
>>
>> Is anyone by chance seeing autofs in the backtrace too?
>>
>>
>>
>> Hello Cy Shubert,
>>
>> I forgot to mention that those crashes occur with autofs mounted
>> filesystems. Good question,
>> by the way, I will check whether crashes also happen when mounting the
>> tradidional way.
>>
>> Kind regards,
>>
>> oh
>>
>> --
>> O. Hartmann
