dcache_lock deadlock due to auditing

[Serge Hallyn <serue@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?

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.