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

[serue at us.ibm.com]

----- Forwarded message from serue at us.ibm.com -----

Date: Tue, 12 Apr 2005 22:13:20 -0500
From: serue at us.ibm.com
To: selinux at tycho.nsa.gov
Subject: dcache_lock deadlock due to auditing
Reply-To: serue at 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 -----