Hi Stephen, Thanks for the quick reply. On Tue, Nov 19, 2019 at 01:59:40PM -0500, Stephen Smalley wrote: > On 11/19/19 1:40 PM, Will Deacon wrote: > > 'avc_compute_av()' can block, so we carefully exit the RCU read-side > > critical section before calling it in 'avc_has_perm_noaudit()'. > > Unfortunately, if we're calling from the VFS layer on the RCU path walk > > via 'selinux_inode_permission()' then we're still actually in an RCU > > read-side critical section and must not block. > > avc_compute_av() should never block AFAIK. The blocking concern was with > slow_avc_audit(), and even that appears dubious to me. That seems to be more > about misuse of d_find_alias in dump_common_audit_data() than anything. Apologies, I lost track of GFP_ATOMIC when I reading the code and didn't think it was propagated down to all of the potential allocations and string functions. Having looked at it again, I can't see where it blocks. Might be worth a comment in avc_compute_av(), because the temporary dropping of rcu_read_lock() looks really dodgy when we could be running on the RCU path walk path anyway. Will
