On Fri, Mar 20, 2015 at 03:39:30PM +1100, NeilBrown wrote: > rcu_read_unlock(); > security_compute_av(ssid, tsid, tclass, avd); > rcu_read_lock(); > > (yes: unlock, and then lock). > > so avc_has_perm_noaudit needs to bail out of RCU-walk if node turns out to be > NULL. NFI, but since a) the guts of security_compute_av() are under rwlock (shared), I rather doubt that it could e.g. block b) avc_has_perm_noaudit() is called from selinux_inode_permission(), which is called inside RCU-walk - it's hit on selinux setups in every successful inode_permission() I'd say that it's no worse than it already was. AFAICS, it's a slowpath and we don't want to hold rcu_read_lock() over it to avoid stalls, but if the caller of avc_has_perm_noaudit() used to want rcu_read_lock(), well, we'll just risks stalls -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
