illumos gate

This happens because after the (forced) zpool export (with no SMB "unshare"), all file system operations under the share root fail. There's one place in smb_common_open where the failure handling logic is incomplete. Actually it looks like this logic problem has been there for a long time, and went unnoticed because this error handling code path is not normally taken.
Specifically, see the "fnode" variable initialization in the PR.
Confirmed with dtrace, after the zpool export, the call to smb_node_getattr on line 442 returns EIO (and probably every file system operation returns EiO after the export). That exposed the logic error were we had set "fnode_held" but not "fnode".

Upstreaming this fix from racktop:
commit 7da3de6ca08cbd76e65e218d2a6335b71205fbaf
Author: Gordon Ross <gwr@racktopsystems.com>
Date: Thu Jun 2 19:18:26 2022 -0400

BSR-11507 panic in smb_common_open after pool export

Test method:

Mount some SMB Share in the pool that will be exported.
Disable the SMB server "unexport" thread as follows:
(Set the "sth_state" field to zero)

# mdb -kw
...
> ::smblist
SERVER           ZONE STATE                            
fffffe170b04f500 0    RUNNING                          
> fffffe170b04f500 ::print -a smb_server_t sv_export.e_unexport_thread
fffffe170b04faf0 sv_export.e_unexport_thread = {
    fffffe170b04faf0 sv_export.e_unexport_thread.sth_magic = 0x534d4254
    fffffe170b04faf4 sv_export.e_unexport_thread.sth_name = [ "smb_kshare_unexport" ]
    fffffe170b04fb14 sv_export.e_unexport_thread.sth_state = 1 (SMB_THREAD_STATE_RUNNING)
    fffffe170b04fb18 sv_export.e_unexport_thread.sth_th = 0xfffffe001f753c20
    fffffe170b04fb20 sv_export.e_unexport_thread.sth_did = 0x120e
    fffffe170b04fb28 sv_export.e_unexport_thread.sth_ep = smb_kshare_unexport_thread
    fffffe170b04fb30 sv_export.e_unexport_thread.sth_ep_arg = 0xfffffe170b04f500
    fffffe170b04fb38 sv_export.e_unexport_thread.sth_pri = 0x3c
    fffffe170b04fb3c sv_export.e_unexport_thread.sth_kill = 0 (0)
    fffffe170b04fb40 sv_export.e_unexport_thread.sth_mtx = {
        fffffe170b04fb40 _opaque = [ 0 ]
    }
    fffffe170b04fb48 sv_export.e_unexport_thread.sth_cv = {
        fffffe170b04fb48 _opaque = 0x1
    }
}
> 
> fffffe170b04fb14/X
0xfffffe170b04fb14:             1               
> fffffe170b04fb14/W0
0xfffffe170b04fb14:             0x1             =       0x0
> 

Forcefully export the zpool:

 zpool export -ff data 

Now in the SMB client that has the share mounted, try refreshing the directory listing.
eg. with the samba client, it should return an error after the zpool export.

smb: \> dir
NT_STATUS_INTERNAL_ERROR listing \*

Before this fix, the server would panic at this point.