Bug 242184 - r354398 causes panic in nfs_unmount during shutdown
Summary: r354398 causes panic in nfs_unmount during shutdown
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 12.0-STABLE
Hardware: amd64 Any
: --- Affects Only Me
Assignee: freebsd-fs (Nobody)
Keywords: panic, regression
Depends on:
Reported: 2019-11-24 07:13 UTC by rk
Modified: 2019-12-02 00:58 UTC (History)
2 users (show)

See Also:

core.txt.3 (94.01 KB, text/plain)
2019-11-24 07:13 UTC, rk
no flags Details
Check for reclaimed vnode after lock (844 bytes, patch)
2019-11-28 12:20 UTC, Konstantin Belousov
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description rk 2019-11-24 07:13:00 UTC
Created attachment 209375 [details]

Recent 12.1-STABLE kernels panic on every reboot/shutdown in nfs_unmount (when NFS file systems are mounted). I tracked it down to the change in r354398:

  MFC r353891:
  Fix interface between nfsclient and vnode pager. 

Starting with r354398 the system panics on every reboot/shutdown while
mounted NFS file systems are present:

Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 10
fault virtual address   = 0x18
fault code              = supervisor write data, page not present
instruction pointer     = 0x20:0xffffffff80acc688
stack pointer           = 0x28:0xfffffe0075d55350
frame pointer           = 0x28:0xfffffe0075d553a0
code segment            = base rx0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = 1 (init)
trap number             = 12
panic: page fault
cpuid = 0
time = 1574577411
KDB: stack backtrace:
#0 0xffffffff80c1d917 at kdb_backtrace+0x67
#1 0xffffffff80bd0dad at vpanic+0x19d
#2 0xffffffff80bd0c03 at panic+0x43
#3 0xffffffff810aa82c at trap_fatal+0x39c
#4 0xffffffff810aa87f at trap_pfault+0x4f
#5 0xffffffff810a9eb1 at trap+0x2a1
#6 0xffffffff8108364c at calltrap+0x8
#7 0xffffffff8122ea0c at VOP_LOCK1_APV+0x7c
#8 0xffffffff80cb26f4 at _vn_lock+0x44
#9 0xffffffff80ca1a88 at vputx+0x138
#10 0xffffffff80ba903d at lf_free_lock+0x25d
#11 0xffffffff80ba940f at lf_purgelocks+0x2df
#12 0xffffffff80c8ffa4 at vop_stdadvlockpurge+0x14
#13 0xffffffff8122f4bc at VOP_ADVLOCKPURGE_APV+0x7c
#14 0xffffffff80ca2a38 at vgonel+0x248
#15 0xffffffff80ca2112 at vflush+0x312
#16 0xffffffff80ad3865 at nfs_unmount+0xd5
#17 0xffffffff80c99e09 at dounmount+0x579

Revision r354394 is stable.
Core information core.txt.3 is attached. I can make vmcore available when needed.
Comment 1 Mark Linimon freebsd_committer freebsd_triage 2019-11-28 10:33:08 UTC
Notify committer of r354398.
Comment 2 Konstantin Belousov freebsd_committer 2019-11-28 12:20:48 UTC
Created attachment 209509 [details]
Check for reclaimed vnode after lock
Comment 3 rk 2019-11-29 08:05:10 UTC
No panics during reboot/shutdown seen so far after applying the fix from attachment 209509 [details] (Check for reclaimed vnode after lock). Thanks.
Comment 4 commit-hook freebsd_committer 2019-11-29 13:56:22 UTC
A commit references this bug:

Author: kib
Date: Fri Nov 29 13:55:56 UTC 2019
New revision: 355210
URL: https://svnweb.freebsd.org/changeset/base/355210

  In nfs_lock(), recheck vp->v_data after lock before accessing it.

  We might race with reclaim, and then this is no longer a nfs vnode, in
  which case we do not need to handle deferred vnode_pager_setsize()

  Reported by:	rk@ronald.org
  PR:	 242184
  Sponsored by:	The FreeBSD Foundation
  MFC after:	3 days

Comment 5 commit-hook freebsd_committer 2019-12-02 00:40:50 UTC
A commit references this bug:

Author: kib
Date: Mon Dec  2 00:39:59 UTC 2019
New revision: 355279
URL: https://svnweb.freebsd.org/changeset/base/355279

  MFC r355210:
  In nfs_lock(), recheck vp->v_data after lock before accessing it.

  PR:	242184

_U  stable/12/