Re: NFSv4 crash of CURRENT

From: Peter Blok <pblok_at_bsd4all.org>
Date: Mon, 15 Jan 2024 08:31:16 UTC
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 <freebsd@walstatt-de.de> wrote:
> 
> Am Sun, 14 Jan 2024 20:34:12 -0800
> Cy Schubert <Cy.Schubert@cschubert.com <mailto:Cy.Schubert@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-lists@klop.ws>=
>>> wrote:  
>>>> 
>>>> 
>>>> Van: FreeBSD User <freebsd@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