panic in smb_request_alloc / smb_oplock_ind_break during shutdown
During an SMB service restart with combined NFS and SMB work underway, observed a panic like this:
smb_request_alloc smb_oplock_ind_break smb_oplock_break_cmn smb_oplock_break_OPEN smb_fem_oplock_open vhead_open fop_open rfs4_do_open rfs4_do_openfh rfs4_op_open
There's a fix for this from nexenta@1da432d9ca360b955f549d36acdd87d52f257b6a
Updated by Gordon Ross 14 days ago
- Status changed from New to In Progress
Don't have the crash dump handy anymore, but from notes:
(and what one can see in the fix on github/Nexenta)
The FEM hook for causing an oplock break is trying to allocate an smb request on a session that's going away.
This appears to have happened because we're holding an ofile ref. and the server is in the process of
getting rid of all those (sessions, ofiles, nodes). That part of the shutdown path does not expect any
new smb requests to be possible on the session, but the oplock break path can try to create one.
(by this point during shutdown, no more taskq jobs should be possible.)
The fix is to make sure a running oplock break task deals correctly with failure to allocate a request
(which is normal and expected on a session or server that's shutting down) and
make sure oplock break tasks jobs can be killed off promptly during shutdown.
Also make sure the FEM hooks are gone away during node destruction.
(That part is done with #14866)