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?

Currently the team is testing Stephen's patch (from march 31) to see whether it is sufficient.

thanks,
-serge

--

Serge Hallyn <serue@us.ibm.com>

--

This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. Received on Thu 14 Apr 2005 - 09:54:29 EDT