[serue@us.ibm.com: dcache_lock deadlock due to auditing]

----- Forwarded message from serue(a)us.ibm.com ----- Date: Tue, 12 Apr 2005 22:13:20 -0500 From: serue(a)us.ibm.com To: selinux(a)tycho.nsa.gov Subject: dcache_lock deadlock due to auditing Reply-To: serue(a)us.ibm.com Hi, a team running some tcp benchmarks on new hardware found a recursive spinlock(dcache_lock) deadlock. It seems to always be caused by: A process is doing a d_alloc() which does a spin_lock(dcache_lock). It is interrupted to receive a packet selinux_sock_rcv_skb gets called it calls avc_has_perm this calls avc_audit this calls audit_log_d_path this calls d_path which does spin_lock(dcache_lock) Deferring the actual audit work to the audit subsystem in a manner similar to what Stephen's recent audit_log_exit() patch did seems one possible way to solve this problem. Another might be to determine our context before the audit_log_d_path( vma->vm_file->f_dentry ), and, if we can determine that we were called from interrupt, simply print out the f_dentry->d_name.name itself. Are there other solutions? thanks, -serge ----- End forwarded message -----