The security_load_policy function calls policydb_read to create an in-memory representation of the new configuration. It then applies the services.c:validate_class function to each entry in the class hash table to verify that each class that is defined under the existing policy is still defined with the same attributes in the new policy. Since the class and permission values are compiled into the object managers, the security server cannot permit its values for existing classes and permissions to change during system operation.
After checking the classes, the security_load_policy function applies the services.c:convert_context function to each entry in the SID hash table to convert the values of users, roles, types, sensitivities and categories in the security context structure for each SID to the corresponding values in the new policy. This function calls mls.c:mls_convert_context to convert the MLS fields of the structure. After converting all of the values, this function also calls policydb_context_isvalid to verify that the context is still valid under the new policy. If it is not, then the SID is removed from the SID hash table.
The security_load_policy function then installs the new policy configuration as the active policy, increments the latest_granting counter, and calls the avc_ss_reset interface of the AVC component to reset the AVC. The global spin lock (ss_lock) is released before calling the AVC. This is necessary because the AVC invokes any callback functions registered by the object managers for resets, and these callback functions may perform permission checks to revalidate permissions that are retained in the state of the object managers.