Bug 228426 - [lor] isofs devfs when rebooting the system after successful installation
Summary: [lor] isofs devfs when rebooting the system after successful installation
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-fs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-05-22 16:37 UTC by Benedict Reuschling
Modified: 2021-11-02 18:25 UTC (History)
2 users (show)

See Also:

Attachments
LOR on 12-CURRENT shutdown after install is complete (77.23 KB, image/jpeg)
2018-05-22 16:37 UTC, Benedict Reuschling 		no flags Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Benedict Reuschling freebsd_committer freebsd_triage 2018-05-22 16:37:40 UTC 
Created attachment 193618 [details]
LOR on 12-CURRENT shutdown after install is complete

I'm getting the attached LOR when I install the FreeBSD 12-CURRENT snapshot r333017 on a Dell C6220 system. It happens with the i386 ISO (the screenshot is from amd64, with identical lines in vfs_mount and vfs_subr), too. It's difficult to get more information as the system is in the process of shutting down. I can reproduce the LOR on that system with a new install reliably.
FreeBSD 11.1 does not have that LOR and the 11.2-BETA2 ISOs I was testing (amd64 and i386) also do not emit that warning.
Comment 1 Conrad Meyer freebsd_committer freebsd_triage 2018-05-22 16:54:02 UTC 
CURRENT is a WITNESS kernel.  11.1 is not.  I suspect 11.2-BETA2 is not either. 
 Non-WITNESS kernels will never print LORs.  So the distinction from 11.x is not really surprising.

Here's the transcribed LOR for other readers:
lock order reversal:
 1st ... isofs (isofs) @ .../sys/kern/vfs_mount.c:1335
 2nd ... devfs (devfs) @ .../sys/kern/vfs_subr.c:2570

(No other stack or previous order info.)

I'm not sure if this is a known LOR or not.  I'll look briefly.
Comment 2 Conrad Meyer freebsd_committer freebsd_triage 2018-05-22 16:57:36 UTC 
Looks like a maybe similar LOR was reported in PR 161112 (FBSD 9 era).  The stack there is:

witness_checkorder+0x839
__lockmgr_args(c4a835a8,80400,c4a835c8,0,0,...) at __lockmgr_args+0x824
vop_stdlock(e7365af0,c0f30e50,e7365af4,80400,c4a83550,...) at vop_stdlock+0x62
VOP_LOCK1_VPU(c101f020,e7365af0,c4c30110,c1059a80,c4a83550,...) at VOP_LOCK1_APV+0xb5
vn_lock(c4a83550,80400,c0f30e50,55b,c492bd00,...) at _vn_lock+0x5e
ffs_flushfiles(c496e798,2,c4b432e0,0,c1059aa0,...) at ffs_flushfiles+0xa7
ffs_unmount(c496e798,80000,e7365bc8,4ef,e7365bf8,...) at ffs_unmount+0x180
dounmount(c496e798,80000,c4b432e0,d8d3ec2c,0,...) at dounmount+0x4a1
vfs_unmountall(c0efb5ad,0,c0efb4fb,139,c09e17da,...) at vfs_unmountall+0x4e
kern_reboot(8,0,c0efb4fb,ba,2,...) at kern_reboot+0x4d2
sys_reboot(c4b432e0,e7365cec,c0f493b6,e7365d80,246,...) at sys_reboot+0x6c

The same LOR as 161112 was reported in PR 144929 comment #2 (9-CURRENT).
Comment 3 Conrad Meyer freebsd_committer freebsd_triage 2018-05-22 16:58:13 UTC 
(No action was taken on either of these LORs, at least according to Bugzilla, so it is possible this is the same LOR.  Yes, the line numbers are significantly different but functions sometimes move around.)