FBSD: Disable background stores 85/14185/6
authorAndrew Deason <adeason@dson.org>
Sun, 3 May 2020 15:26:27 +0000 (10:26 -0500)
committerBenjamin Kaduk <kaduk@mit.edu>
Tue, 14 Sep 2021 16:37:15 +0000 (12:37 -0400)
commit92222d023142b06ac148778263f6cef6115f9cfb
treec98d81ed5caa627d9831095d8bcedd7e83b79877
parenta3aac5106beddc5a6f7a09c2d21c2524342aca01
FBSD: Disable background stores

Currently, when closing a vcache (via afs_close), we write any dirty
data to the net, and we do so via a background daemon if one is
available (for the rarely-used 'fs storebehind' functionality).

However, on FBSD, this breaks the locking rules, since flushing dirty
pages for a vnode requires the vnode to be locked. In the situation
where we are writing via a background daemon, the afs_close() thread
is what holds the vnode lock, but the background thread is the one
that's actually flushing the dirty pages. So the vnode is effectively
locked in this situation, but to the FreeBSD kernel it looks like we
are flushing pages without the vnode lock, and so it complains:

    kernel: KDB: stack backtrace:
    kernel: #0 0xffffffff80bf6557 at kdb_backtrace+0x67
    kernel: #1 0xffffffff80c7a337 at assert_vop_locked+0x77
    kernel: #2 0xffffffff811fc0bb at VOP_PUTPAGES_APV+0x7b
    kernel: #3 0xffffffff80f016bd at vnode_pager_putpages+0x7d
    kernel: #4 0xffffffff80ef424f at vm_pageout_flush+0xff
    kernel: #5 0xffffffff80ee9b39 at vm_object_page_collect_flush+0x239
    kernel: #6 0xffffffff80ee9819 at vm_object_page_clean+0x179
    kernel: #7 0xffffffff828d7181 at osi_VM_StoreAllSegments+0x111
    kernel: #8 0xffffffff82850a3d at afs_StoreAllSegments+0x9d
    kernel: #9 0xffffffff8287b1ce at afs_StoreOnLastReference+0x17e
    kernel: #10 0xffffffff8282dc70 at BStore+0xd0
    kernel: #11 0xffffffff8282d6ec at afs_BackgroundDaemon+0x2cc
    kernel: #12 0xffffffff828c2f2f at afs_syscall_call+0x35f
    kernel: #13 0xffffffff82855963 at afs3_syscall+0x83
    kernel: #14 0xffffffff81074581 at amd64_syscall+0x291
    kernel: #15 0xffffffff8104cde0 at fast_syscall_common+0x101
    kernel: vnode 0xfffff8006974fc58: tag afs, type VREG
    kernel:     usecount 2, writecount 0, refcount 3
    kernel:     flags (VI_ACTIVE)
    kernel:     v_object 0xfffff80023917900 ref 0 pages 171 cleanbuf 0 dirtybuf 0
    kernel:     lock type afs: EXCL by thread 0xfffff800852775e0 (pid 31828, ld.lld, tid 100787)
    kernel: #0 0xffffffff80b81fc2 at lockmgr_lock_fast_path+0x1e2
    kernel: #1 0xffffffff811fa9f6 at VOP_LOCK1_APV+0x96
    kernel: #2 0xffffffff80c8c705 at _vn_lock+0x65
    kernel: #3 0xffffffff80c8c8a3 at vn_close1+0x73
    kernel: #4 0xffffffff80c8b76c at vn_closefile+0x4c
    kernel: #5 0xffffffff80b571ba at _fdrop+0x1a
    kernel: #6 0xffffffff80b5a3cc at closef+0x1ec
    kernel: #7 0xffffffff80b577be at closefp+0x9e
    kernel: #8 0xffffffff81074581 at amd64_syscall+0x291
    kernel: #9 0xffffffff8104cde0 at fast_syscall_common+0x101
    kernel: vc 0xfffffe002b8d4d30 vp 0xfffff8006974fc58 tag afs, fid: 1.536870912.13317022.33596982, opens 1, writers 1
    kernel:   states statd dirty
    kernel: VOP_PUTPAGES: 0xfffff8006974fc58 is not locked but should be

To avoid this, force afs_close() to write dirty data in the same
thread, instead of passing it off to a background daemon.

Change-Id: Id952c7928c301fcc35d226e117dc19010b42776a
Reviewed-on: https://gerrit.openafs.org/14185
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
src/afs/VNOPS/afs_vnop_write.c