On Fri, 2005-05-20 at 11:09 -0400, Stephen Smalley wrote:
The lock is being held by the af_unix code (unix_state_wlock), not
avc_audit; the AVC is called under all kinds of circumstances (softirq,
hard irq, caller holding locks on relevant objects) for permission
checking and must never sleep.
One option might be to defer some of the AVC auditing to the audit
framework (e.g. save the vfsmount and dentry on the current audit
context and let audit_log_exit perform the audit_log_d_path).
Yeah, maybe. Assuming you pin them, it's easy enough to hang something
off the audit context's aux list which refers to them. I'm really not
that fond of the idea of allocating a whole PATH_MAX with GFP_ATOMIC.
--
dwmw2