panic in smbfs_delmap_callback
Discovered this while running SMB clients tests on a larger, faster machine,
running the code integrated with #5404 (smbfs mmap support)
> $C ffffff00bc6d0cc0 smbfs_delmap_callback+0x3e(ffffff26ba54d800, ffffff368bf84050, 7) ffffff00bc6d0d10 as_execute_callback+0x6a(ffffff26ba54d800, ffffff46fcdce160, 7) ffffff00bc6d0d50 as_do_callbacks+0x4e(ffffff26ba54d800, 7, 0, 0) ffffff00bc6d0db0 as_free+0x63(ffffff26ba54d800) ffffff00bc6d0de0 relvm+0x28c() ffffff00bc6d0e70 proc_exit+0x4d0(1, 0) ffffff00bc6d0e90 exit+0x15(1, 0) ffffff00bc6d0eb0 rexit+0x18(0) ffffff00bc6d0f00 _sys_sysenter_post_swapgs+0x234()
Found while running the SUNWstc tests, at or around smbfs/mvdir
Updated by Gordon Ross almost 3 years ago
It turns out that a delmap callback can run after segvn_free has dropped the last vnode reference, which is what led to the panic described here (the vnode points to free'd memory).
The first attempt at fixing this was to simply take a hold on the vnode in smbfs_delmap (where we request the callback) and release it at the end of the callback function.
Unfortunately, that revealed that the as_add_callback facility is not guaranteed to call the callback you give it, which with the "just take a hold" approach means we leak a vnode reference, which then causes many other structures to hang around (the smbfs mount, the connected share, the session).
The second fix uses a taskq for the work that we can't do directly in smbfs_delmap.
Having a taskq in each smbfs mount will also facilitate adding async write support later.
Out for review: https://www.illumos.org/rb/r/1067/
Updated by Electric Monk almost 3 years ago
- Status changed from In Progress to Closed
- % Done changed from 0 to 100
commit 4e72ade1d48747d1105e26d42fc4787278f8f35e Author: Gordon Ross <email@example.com> Date: 2018-04-13T19:26:29.000Z 9462 panic in smbfs_delmap_callback Reviewed by: Jean McCormack <firstname.lastname@example.org> Reviewed by: Dan Fields <email@example.com> Reviewed by: Evan Layton <firstname.lastname@example.org> Reviewed by: Toomas Soome <email@example.com> Approved by: Albert Lee <firstname.lastname@example.org>