On Wed, 2025-01-22 at 18:24 +0100, Roberto Sassu wrote: > From: Roberto Sassu <roberto.sa...@huawei.com> > > Move out the mutex in the ima_iint_cache structure to a new structure > called ima_iint_cache_lock, so that a lock can be taken regardless of > whether or not inode integrity metadata are stored in the inode. > > Introduce ima_inode_security() to retrieve the ima_iint_cache_lock > structure, if inode i_security is not NULL, and consequently remove > ima_inode_get_iint() and ima_inode_set_iint(), since the ima_iint_cache > structure can be read and modified from the new structure. > > Move the mutex initialization and annotation in the new function > ima_inode_alloc_security() and introduce ima_iint_lock() and > ima_iint_unlock() to respectively lock and unlock the mutex. > > Finally, expand the critical region in process_measurement() guarded by > iint->mutex up to where the inode was locked, use only one iint lock in > __ima_inode_hash(), since the mutex is now in the inode security blob, and > replace the inode_lock()/inode_unlock() calls in ima_check_last_writer(). > > Signed-off-by: Roberto Sassu <roberto.sa...@huawei.com> > Reviewed-by: Paul Moore <p...@paul-moore.com>
Reviewed-by: Mimi Zohar <zo...@linux.ibm.com>
