Re: Repeatable nfs_readdir kernel panic after upgrade to stable/14

Indeed, seems to work now. Thanks for the speedy fix.

On Wed, 17 Jan 2024, 11:07 Konstantin Belousov, <kib@freebsd.org> wrote:

> On Wed, Jan 17, 2024 at 10:28:01AM +0100, Ulrich Spörlein wrote:
> > Hey there,
> > upgraded my NFS server and laptop (NFS client) to stable/14 over the
> > weekend and now anything "intensive" that reads from NFS seems to kernel
> > panic.
> >
> > I think this started when I upgraded the server first, shrugged it off as
> > some overload on the laptop, finished the laptop upgrade to 14 and now
> > everytime I open easytag on the NFS automounted directory, or browsing
> > photos with geeqie it locks up hard.
> >
> > Mounts on the client currently look like so:
> >
> > map /etc/auto_tank on /tank (autofs)
> > map -media on /media (autofs)
> > 192.168.0.151:/tank/music on /tank/music (nfs, automounted)
> >
> > I'm not even sure if I'm using NFS3 or 4 or whether I'm using the ZFS
> based
> > one, I've set this up ages ago.
> >
> > Fatal trap 12: page fault while in kernel mode
> > cpuid = 1; apic id = 02
> > fault virtual address   = 0x89
> > fault code              = supervisor read data, page not present
> > instruction pointer     = 0x20:0xffffffff80eee094
> > stack pointer           = 0x28:0xfffffe01268c0830
> > frame pointer           = 0x28:0xfffffe01268c0830
> > 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         = 74673 (easytag)
> > rdi: 0000000000000000 rsi: ffffffff819bff08 rdx: 0000000000000000
> > rcx: 0000000000000000  r8: fffffe003781e0f0  r9: fffff8001ab51740
> > rax: 0000000000000000 rbx: fffff8001ab51740 rbp: fffffe01268c0830
> > r10: ffffffff00000000 r11: fffffe01268c07b0 r12: fffffe003781e0f0
> > r13: fffff8047ac47700 r14: fffffe012ac1ba38 r15: fffff80437cac000
> > trap number             = 12
> > panic: page fault
> > cpuid = 1
> > time = 1705480771
> > KDB: stack backtrace:
> > #0 0xffffffff80b9d68d at kdb_backtrace+0x5d
> > #1 0xffffffff80b4f95f at vpanic+0x12f
> > #2 0xffffffff80b4f823 at panic+0x43
> > #3 0xffffffff8102902f at trap_fatal+0x40f
> > #4 0xffffffff8102907f at trap_pfault+0x4f
> > #5 0xffffffff80ffef48 at calltrap+0x8
> > #6 0xffffffff80a3a3fe at ncl_bioread+0xb7e
> > #7 0xffffffff80a2c0a0 at nfs_readdir+0x1f0
> > #8 0xffffffff80c217aa at vop_sigdefer+0x2a
> > #9 0xffffffff81100280 at VOP_READDIR_APV+0x20
> > #10 0xffffffff846af5ae at autofs_readdir+0x2ce
> > #11 0xffffffff81100280 at VOP_READDIR_APV+0x20
> > #12 0xffffffff80c48501 at kern_getdirentries+0x221
> > #13 0xffffffff80c488a9 at sys_getdirentries+0x29
> > #14 0xffffffff810298d9 at amd64_syscall+0x109
> > #15 0xffffffff80fff85b at fast_syscall_common+0xf8
> > Uptime: 3m18s
> > Dumping 1242 out of 32368
> > MB:..2%..11%..21%..31%..42%..51%..61%..71%..82%..91%
> >
> > I can still access those NFS mounts just fine, can play music off them
> with
> > audacious or just mpv, but easytag will try to recursively read
> everything
> > and presumably puts a lot of stress on the system.
> >
> > I see there was chatter about this recently, and kib committed something
> to
> > nfsclient, which got merged to stable/14 on the 11th, but my build is
> from
> > the 14th, so presumably I already have this "fix", and it's not working?
> >
> > I'm on n266311-299e9fe9709a right now, which _is_ after kib's fixes,
> maybe
> > they are not sufficient for stable/14?
>
> You need 7b49e60227f8 which I just pushed.
>
>