Bug #6472
Panic in rfs4_compound_kstat_res()
Added by Marcel Telka over 5 years ago.
Updated over 4 years ago.
Category:
nfs - NFS server and client
Description
Reported by somebody on IRC:
panic[cpu2]/thread=ffffff0936b2cae0:
mutex_enter: bad mutex, lp=ffffff09370e2908 owner=ffffff0936b2cae0 thread=ffffff0936b2cae0
ffffff003e0866f0 unix:mutex_panic+58 ()
ffffff003e086760 unix:mutex_vector_enter+347 ()
ffffff003e086790 nfssrv:exi_rele+26 ()
ffffff003e0867f0 nfssrv:rfs4_compound_kstat_res+113 ()
ffffff003e0868b0 nfssrv:rfs4_dispatch+1b8 ()
ffffff003e086c20 nfssrv:common_dispatch+b2c ()
ffffff003e086c40 nfssrv:rfs_dispatch+2d ()
ffffff003e086d20 rpcmod:svc_getreq+1c1 ()
ffffff003e086d90 rpcmod:svc_run+e0 ()
ffffff003e086dd0 rpcmod:svc_do_run+8e ()
ffffff003e086ec0 nfs:nfssys+111 ()
ffffff003e086f10 unix:brand_sys_sysenter+1c9 ()
- Related to Bug #6090: IOPS, bandwidth, and latency kstats for NFS server added
- Status changed from New to In Progress
- Related to Bug #6696: Per-client NFS server IOPS, bandwidth, and latency kstats added
Root Cause
The rfs4_compound_kstat_res() is called from rfs4_dispatch() to update the kstats once the reply is sent back to the client. The rfs4_compound_kstat_res() updates the kstats, but it also calls exi_rele(). This is incorrect, because in rfs4_compound_kstat_res() we do not release resources, we just update the stats. This exi_rele() call in rfs4_compound_kstat_res() causes two possible issues:
- When the reply is not sent successfully (the svc_sendreply() call fails) the exi_rele() is never called.
- In a case the reply is stored in DRC and replayed, the exi_rele() is called twice. If the particular exportinfo disappeared in the meantime, we might see the panic.
The resource release should be done in rfs4_compound_free() instead.
- Has duplicate Bug #7188: Panic in rfs4_compound_kstat_res added
- Status changed from In Progress to Feedback
This bug was introduced by #6090, which was recently backed out.
- Status changed from Feedback to Closed
Also available in: Atom
PDF